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Introduction 


People  have  been  undertaking  projects  since  the  earliest  days  of  organized  human  activity.  The  hunting  parties  of 
our  prehistoric  ancestors  were  projects.  Large  complex  projects  such  as  the  pyramids  and  the  Great  Wall  of  China 
were  also  projects.  Even  something  as  simple  as  creating  a  dinner  is  considered  a  project.  We  use  the  term  “pro¬ 
ject”  frequently  in  our  daily  conversations.  This  book  covers  the  basics  of  project  management.  This  includes  the 
process  of  initiation,  planning,  execution,  control,  and  closeout  that  all  projects  share. 


Preface 


The  primary  purpose  of  this  text  is  to  provide  an  open  source  textbook  that  covers  most  project  management 
courses.  The  material  in  the  textbook  was  obtained  from  a  variety  of  sources.  All  the  sources  are  found  in  the 
reference  section  at  the  end  of  each  chapter.  I  expect,  with  time,  the  book  will  grow  with  more  information  and 
more  examples. 

I  welcome  any  feedback  that  would  improve  the  book.  If  you  would  like  to  add  a  section  to  the  book,  please  let 
me  know. 


About  the  Book 


Project  Management  is  a  remix  and  adaptation.  The  adaptation  is  a  part  of  the  BCcampus  Open  Textbook  project. 

The  B.C.  Open  Textbook  Project  began  in  2012  with  the  goal  of  making  post-secondary  education  in  British 
Columbia  more  accessible  by  reducing  student  cost  through  the  use  of  openly  licensed  textbooks.  The  BC  Open 
Textbook  Project  is  administered  by  BCcampus  and  funded  by  the  British  Columbia  Ministry  of  Advanced  Edu¬ 
cation. 

Open  textbooks  are  open  educational  resources  (OER);  they  are  instructional  resources  created  and  shared  in  ways 
so  that  more  people  have  access  to  them.  This  is  a  different  model  than  traditionally  copyrighted  materials.  OER 
are  defined  as  teaching,  learning,  and  research  resources  that  reside  in  the  public  domain  or  have  been  released 
under  an  intellectual  property  license  that  permits  their  free  use  and  re-purposing  by  others  (Hewlett  Founda¬ 
tion).  Our  open  textbooks  are  openly  licensed  using  a  Creative  Commons  license,  and  are  offered  in  various  e- 
book  formats  free  of  charge,  or  as  printed  books  that  are  available  at  cost.  For  more  information  about  this  project, 
please  contact  opentext@bccampus.ca.  If  you  are  an  instructor  who  is  using  this  book  for  a  course,  please  let  us 
know. 
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1 .  Project  Management:  Past  and  Present 


ADRIENNE  WATT 


Careers  Using  Project  Management  Skills 

Skills  learned  by  your  exposure  to  studying  project  management  can  be  used  in  most  careers  as  well  as  in  your 
daily  life.  Strong  planning  skills,  good  communication,  ability  to  implement  a  project  to  deliver  the  product  or  ser¬ 
vice  while  also  monitoring  for  risks  and  managing  the  resources  will  provide  an  edge  toward  your  success.  Project 
managers  can  be  seen  in  many  industry  sectors  including  agriculture  and  natural  resources;  arts,  media,  and  enter¬ 
tainment;  building  trades  and  construction;  energy  and  utilities;  engineering  and  design;  fashion  and  interiors; 
finance  and  business;  health  and  human  services;  hospitality,  tourism,  and  recreation;  manufacturing  and  product 
development;  public  and  private  education  services;  public  services;  retail  and  wholesale  trade;  transportation; 
and  information  technology. 

Below  we  explore  various  careers  and  some  of  the  ways  in  which  project  management  knowledge  can  be  lever¬ 
aged. 

Business  Owners 

Business  owners  definitely  need  to  have  some  project  management  skills.  With  all  successful  businesses,  the  prod¬ 
uct  or  service  being  delivered  to  the  customer  meets  their  needs  in  many  ways.  The  product  or  service  is  of  the 
quality  desired,  the  costs  are  aligned  with  what  the  consumer  expected,  and  the  timeliness  of  the  product  or  ser¬ 
vice  meets  the  deadline  for  the  buyer  of  that  item. 

The  pillars  of  project  management  are  delivering  a  product/service  within  schedule,  cost,  scope,  and  quality 
requirements.  Business  owners  need  planning,  organizing,  and  scoping  skills  and  the  ability  to  analyze,  commu¬ 
nicate,  budget,  staff,  equip,  implement,  and  deliver. 

Understanding  the  finances,  operations,  and  expenses  of  the  business  are  among  the  skills  that  project  managers 
learn  and  practice.  Some  businesses  may  focus  more  on  accounting,  providing  financial  advice,  sales,  training, 
public  relations,  and  actuary  or  logistician  roles.  Business  owners  may  own  a  travel  agency  or  provide  hospitality. 
Business  owners  could  be  managing  a  storefront  or  a  location  in  their  town’s  marketplace. 
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Example:  Restaurant  Owner/Manager 

Restaurant  managers  are  responsible  for  the  daily  operations  of  a  restaurant  that  prepares  and  serves  meals  and 
beverages  to  customers.  Strong  planning  skills,  especially  coordinating  with  the  various  departments  (kitchen, 
dining  room,  banquet  operations,  food  service  managers,  vendors  providing  the  supplies)  ensure  that  customers 
are  satisfied  with  their  dining  experience.  Managers’  abilities  to  recruit  and  retain  employees,  and  monitor 
employee  performance  and  training  ensure  quality  with  cost  containment.  Scheduling  in  many  aspects,  not  only 
the  staff  but  also  the  timing  of  the  food  service  deliveries,  is  critical  in  meeting  customer  expectations. 

Risk  management  is  essential  to  ensure  food  safety  and  quality.  Managers  monitor  orders  in  the  kitchen  to  deter¬ 
mine  where  delays  may  occur,  and  they  work  with  the  chef  to  prevent  these  delays.  Legal  compliance  is  essential 
in  order  for  the  restaurant  to  stay  open,  so  restaurant  managers  direct  the  cleaning  of  the  dining  areas  and  the 
washing  of  tableware,  kitchen  utensils,  and  equipment.  They  ensure  the  safety  standards  and  legality,  especially 
in  serving  alcohol.  Sensitivity  and  strong  communication  skills  are  needed  when  customers  have  complaints  or 
employees  feel  pressured  because  more  customers  arrive  than  predicted. 

Financial  knowledge  is  needed  for  the  soundness  of  running  the  restaurant,  especially  tracking  special  projects, 
events,  and  costs  for  the  various  menu  selections.  Catering  events  smoothly  can  be  an  outcome  of  using  project 
plans  and  the  philosophy  of  project  management.  The  restaurant  manager  or  the  executive  chef  analyzes  the 
recipes  to  determine  food,  labor,  and  overhead  costs;  determines  the  portion  size  and  nutritional  content  of  each 
serving;  and  assigns  prices  to  various  menu  items,  so  that  supplies  can  be  ordered  and  received  in  time. 

Planning  is  the  key  for  successful  implementation.  Managers  or  executive  chefs  need  to  estimate  food  needs,  place 
orders  with  distributors,  and  schedule  the  delivery  of  fresh  food  and  supplies.  They  also  plan  for  routine  services 
(equipment  maintenance,  pest  control,  waste  removal)  and  deliveries,  including  linen  services  or  the  heavy  clean¬ 
ing  of  dining  rooms  or  kitchen  equipment,  to  occur  during  slow  times  or  when  the  dining  room  is  closed.  A  suc¬ 
cessful  restaurant  relies  on  many  skills  that  the  project  management  profession  emphasizes. 

Outsourcing  Services 


Figure  1.1:  Sample  status  chart,  which  is  typical  with  the  use  of  a 
red-yellow-green,  by  Maura  Irene  Jones  in  Project  Management 
Skills  for  All  Careers  (http://textbookequity.org/oct/Textbooks/ 
ProjectManagementforAllCareersEdition2.pdf),  used  under 
CC-BY  license  (https://creativecommons.0rg/licenses/by/3.O/). 


Many  businesses  explore  outsourcing  for  certain  services.  Below  is  a  sample  status  and  project  plan  that  reflects 
the  various  tasks  needed  for  a  project.  A  review  of  finances,  the  importance  of  communicating  to  stakeholders, 
and  the  importance  of  time,  cost,  schedule,  scope,  and  quality  are  reflected.  Many  companies  may  use  these  steps 
in  their  business.  These  plans  show  the  need  for  the  entire  team  to  review  the  various  proposals  to  choose  the  best 
plan.  Figure  1.1  represents  a  sample  project  status  report. 
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Example:  Construction  Managers 

Construction  managers  plan,  direct,  coordinate,  and  budget  a  wide  variety  of  residential,  commercial,  and  indus¬ 
trial  construction  projects  including  homes,  stores,  offices,  roads,  bridges,  wastewater  treatment  plants,  schools, 
and  hospitals.  Strong  scheduling  skills  are  essential  for  this  role.  Communication  skills  are  often  used  in  coordi¬ 
nating  design  and  construction  processes,  teams  executing  the  work,  and  governance  of  special  trades  (carpentry, 
plumbing,  electrical  wiring)  as  well  as  government  representatives  for  the  permit  processes. 

A  construction  manager  may  be  called  a  project  manager  or  project  engineer.  The  construction  manager  ensures 
that  the  project  is  completed  on  time  and  within  budget  while  meeting  quality  specifications  and  codes  and  main¬ 
taining  a  safe  work  environment.  These  managers  create  project  plans  in  which  they  divide  all  required  construc¬ 
tion  site  activities  into  logical  steps,  estimahng  and  budgeting  the  time  required  to  meet  established  deadlines, 
usually  utilizing  sophisticated  scheduling  and  cost-estimating  software.  Many  use  software  packages  such  as 
Microsoft  Project®  or  Procure®  or  online  tools  like  BaseCamp®.  Most  construction  projects  rely  on  spreadsheets 
for  project  management.  Procurement  skills  used  in  this  field  include  acquiring  the  bills  for  material,  lumber  for 
the  house  being  built,  and  more.  Construction  managers  also  coordinate  labor,  determining  the  needs  and  oversee¬ 
ing  their  performance,  ensuring  that  ah  work  is  completed  on  schedule. 

Values  including  sustainability,  reuse,  LEED-certified  building,  use  of  green  energy,  and  various  energy  efficien¬ 
cies  are  being  incorporated  into  today’s  projects  with  an  eye  to  the  future.  Jennifer  Russell,  spoke  about  project 
management  and  global  sustainability”  at  the  2011  Silicon  Valley  Project  Management  Institute  (PMI)  conference. 
She  informed  the  attendees  of  the  financial,  environmental,  and  social  areas  in  expanding  the  vision  of  project 
management  with  the  slide  in  Figure  1.2.  These  values  are  part  of  the  PMI’s  code  of  ethics  and  professionalism. 
By  adhering  to  this  code,  project  managers  include  in  their  decisions  the  best  interests  of  society,  the  safety  of  the 
public,  and  enhancement  of  the  environment. 


Figure  1.2:  Project  Management  by  Jennifer  Russell 
(http://www.tharpo.com/),  used  under  CC-BY  license 

(https://creativecommons.Org/licenses/by/3.0/). 


Creative  Services 

Creative  service  careers  include  graphic  artists,  curators,  video  editors,  gaming  managers,  multimedia  artists, 
media  producers,  technical  writers,  interpreters,  and  translators.  These  positions  use  project  management  skills, 
especially  in  handling  the  delivery  channel  and  meeting  clients’  requirements. 

Let  us  look  at  one  example,  graphic  artists,  to  understand  and  identify  some  of  the  project  management  skills  that 
aid  in  this  career. 

Example:  Graphic  Artists 

Graphic  artists  plan,  analyze,  and  create  visual  solutions  to  communication  problems.  They  use  many  skills  found 
in  project  management,  especially  communications.  They  work  to  achieve  the  most  effective  way  to  get  messages 
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across  in  print  and  electronic  media.  They  emphasize  their  messages  using  color,  type,  illustration,  photography, 
animation,  and  various  print  and  layout  techniques.  Results  can  be  seen  in  magazines,  newspapers,  journals,  cor¬ 
porate  reports,  and  other  publications.  Other  deliverables  from  graphic  artists  using  project  management  skills 
include  promotional  displays,  packaging,  and  marketing  brochures  supporting  products  and  services,  logos,  and 
signage.  In  addition  to  print  media,  graphic  artists  create  materials  for  the  web,  TV,  movies,  and  mobile  device 
apps. 

Initiation  in  project  management  can  be  seen  in  developing  a  new  design:  determining  the  needs  of  the  client,  the 
message  the  design  should  portray,  and  its  appeal  to  customers  or  users.  Graphic  designers  consider  cognitive, 
cultural,  physical,  and  social  factors  in  planning  and  executing  designs  for  the  target  audience,  very  similar  to 
some  of  the  dynamics  a  project  manager  considers  in  communicating  with  various  project  stakeholders.  Designers 
may  gather  relevant  information  by  meeting  with  clients,  creative  staff,  or  art  directors;  brainstorming  with  others 
within  their  firm  or  professional  association;  and  performing  their  own  research  to  ensure  that  their  results  have 
high  quality  and  they  can  manage  risks. 

Graphic  designers  may  supervise  assistants  who  follow  instructions  to  complete  parts  of  the  design  process. 
Therefore  scheduling,  resource  planning,  and  cost  monitoring  are  pillars  of  project  management  seen  in  this  indus¬ 
try.  These  artists  use  computer  and  communications  equipment  to  meet  their  clients’  needs  and  business  require¬ 
ments  in  a  timely  and  cost-efficient  manner. 

Educators 

“Educator”  is  a  broad  term  that  can  describe  a  career  in  teaching,  maybe  being  a  lecturer,  a  professor,  a  tutor,  or  a 
home-schooler.  Other  educators  include  gurus,  mullahs,  pastors,  rabbis,  and  priests.  Instructors  also  provide  voca¬ 
tional  training  or  teach  skills  like  learning  how  to  drive  a  car  or  use  a  computer.  Educators  provide  motivation  to 
learn  a  new  language  or  showcase  new  products  and  services.  Educators  use  project  management  skills  including 
planning  and  communication. 

Let  us  look  at  teachers,  since  we  all  have  had  teachers,  and  see  if  we  can  recognize  the  project  management  skills 
that  are  demonstrated  in  this  profession. 

Example:  Teachers 

Some  teachers  foster  the  intellectual  and  social  development  of  children  during  their  formative  years;  other  teach¬ 
ers  provide  knowledge,  career  skill  sets,  and  guidance  to  adults.  Project  management  skills  that  teachers  exhibit 
include  acting  as  facilitators  or  coaches  and  communicating  in  the  classroom  and  in  individual  instruction.  Project 
managers  plan  and  evaluate  various  aspects  of  a  project;  teachers  plan,  evaluate,  and  assign  lessons;  implement 
these  plans;  and  monitor  each  student’s  progress  similar  to  the  way  a  project  manager  monitors  and  delivers  goods 
or  services.  Teachers  use  their  people  skills  to  manage  students,  parents,  and  administrators.  The  soft  skills  that 
project  managers  exercise  can  be  seen  in  teachers  who  encourage  collaboration  in  solving  problems  by  having 
students  work  in  groups  to  discuss  and  solve  problems  as  a  team. 

Project  managers  may  work  in  a  variety  of  fields  with  a  broad  assortment  of  people,  similar  to  teachers  who 
work  with  students  from  varied  ethnic,  racial,  and  religious  backgrounds.  These  teachers  must  have  awareness 
and  understanding  of  different  cultures. 
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Teachers  in  some  schools  may  be  involved  in  making  decisions  regarding  the  budget,  personnel,  textbooks,  cur¬ 
riculum  design,  and  teaching  methods,  demonstrating  skills  that  a  project  manager  would  possess  such  as  financial 
management  and  decision  making. 

Engineers 

Engineers  apply  the  principles  of  science  and  mathematics  to  develop  economical  solutions  to  technical  problems. 
As  a  project  cycles  from  an  idea  in  the  project  charter  to  the  implementation  and  delivery  of  a  product  or  service, 
engineers  link  scientific  discoveries  to  commercial  applications  that  meet  societal  and  consumer  needs. 

Engineers  use  many  project  management  skills,  especially  when  they  must  specify  functional  requirements. 
They  demonstrate  attention  to  quality  as  they  evaluate  a  design’s  overall  effectiveness,  cost,  reliability,  and  safety 
similar  to  the  project  manager  reviewing  the  criteria  for  the  customer’s  acceptance  of  delivery  of  the  product  or 
service. 

Estimation  skills  in  project  management  are  used  in  engineering.  Engineers  are  asked  many  times  to  provide  an 
estimate  of  time  and  cost  required  to  complete  projects. 

Health  Care 

There  are  many  jobs  and  careers  in  health  care  that  use  project  management  skills.  Occupations  in  the  field 
of  health  care  vary  widely,  such  as  athletic  trainer,  dental  hygienist,  massage  therapist,  occupational  therapist, 
optometrist,  nurse,  physician,  physician  assistant,  and  X-ray  technician.  These  individuals  actively  apply  risk 
management  in  providing  health  care  delivery  of  service  to  their  clients,  ensuring  that  they  do  not  injure  the  person 
they  are  caring  for.  Note:  There  is  a  section  on  nursing  later  in  this  chapter. 

Many  of  you  may  have  had  a  fall  while  you  were  growing  up,  and  needed  an  X-ray  to  determine  if  you  had  a 
fracture  or  merely  a  sprain.  Let  us  look  at  this  career  as  an  example  of  a  health  care  professional  using  project 
management  skills. 

Example:  Radiology  Technologists 

Radiology  technologists  and  technicians  perform  diagnostic  imaging  examinations  like  X-rays,  computed  tomog¬ 
raphy  (CT),  magnetic  resonance  imaging  (MRI),  and  mammography.  They  could  also  be  called  radiographers, 
because  they  produce  X-ray  films  (radiographs)  of  parts  of  the  human  body  for  use  in  diagnosing  medical  prob¬ 
lems. 

Project  management  skills,  especially  people  skills  and  strong  communication,  are  demonstrated  when  they  pre¬ 
pare  patients  for  radiologic  examinations  by  explaining  the  procedure  and  what  position  the  patient  needs  to  be 
in,  so  that  the  parts  of  the  body  can  be  appropriately  radiographed.  Risk  management  is  demonstrated  when  these 
professionals  work  to  prevent  unnecessary  exposure  to  radiation  by  surrounding  the  exposed  area  with  radiation 
protection  devices,  such  as  lead  shields,  or  limiting  the  size  of  the  X-ray  beam.  To  ensure  quality  results,  the  health 
technician  monitors  the  radiograph  and  sets  controls  on  the  X-ray  machine  to  produce  radiographs  of  the  appro¬ 
priate  density,  detail,  and  contrast. 

Safety  and  regulations  concerning  the  use  of  radiation  to  protect  themselves,  their  patients,  and  their  coworkers 
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from  unnecessary  exposure  is  tracked  in  an  efficient  manner  and  reported  as  a  control  to  ensure  compliance.  Pro¬ 
ject  management  skills  are  also  used  in  preparing  work  schedules,  evaluating  equipment  for  purchase,  or  manag¬ 
ing  a  radiology  department. 

Some  radiological  technologists  specialize  in  CT  scans;  as  CT  technologists  they  too  use  project  management 
skills.  CT  uses  ionizing  radiation  to  produce  a  substantial  number  of  cross-sectional  X-rays  of  an  area  of  the  body. 
Therefore,  it  requires  the  same  precautionary  measures  that  are  used  with  X-rays,  hence  the  need  for  risk  manage¬ 
ment  and  monitoring  for  exposure. 

Teamwork,  not  only  with  the  patient  that  the  radiological  technologist  supports  and  the  doctor  who  ordered  the 
request,  but  also  with  other  health  care  providers,  relies  on  strong  communication,  quality,  work  done  in  a  timely 
manner,  and  wise  use  of  hospital  resources.  This  all  boils  down  to  ensuring  that  the  three  elements  of  the  project 
management  triangle  of  cost,  schedule,  and  scope  with  quality  delivered  remain  the  essentials  that  provide  a  cor¬ 
nerstone  to  project  management  and  the  skills  needed  to  obtain  the  objective. 

Example:  Nurses 

Nurses  treat  and  educate  patients  and  their  families  and  the  public  about  various  medical  conditions  and  provide 
advice  and  emotional  support.  Nurses  establish  a  care  plan  for  their  patients  that  include  activities  like  scheduling 
the  administration  and  discontinuation  of  medications  (e.g.,  intravenous  (IV)  lines  for  fluid,  medication,  blood, 
and  blood  products)  and  application  of  therapies  and  treatments.  Communication  with  the  patient,  their  family, 
physicians  and  other  health  care  clinicians  may  be  done  in  person  or  via  technology.  Telehealth  allows  nurses  to 
provide  care  and  advice  through  electronic  communications  media  including  videoconferencing,  the  Internet,  or 
telephone. 

Risk  management  is  very  important  for  a  nurse,  with  some  cases  having  a  life  or  death  consequence.  Nurses  mon¬ 
itor  pain  management  and  vital  signs  and  provide  status  reports  to  physicians  to  help  in  responding  to  the  health 
care  needs  of  the  patient. 

The  nursing  field  varies.  Some  nurses  work  in  infection  control.  They  identify,  track,  and  control  infectious  out¬ 
breaks  in  health  care  facilities  and  create  programs  for  outbreak  prevention  and  response  to  biological  terrorism. 
Others  are  educators  who  plan,  develop,  execute,  and  evaluate  educational  programs  and  curricula  for  the  profes¬ 
sional  development  of  students  and  graduate  nurses.  Nurses  may  use  project  management  skills  while  conducting 
health  care  consultations,  advising  on  public  policy,  researching  in  the  field,  or  providing  sales  support  of  a  prod¬ 
uct  or  service. 

Paralegal 

Attorneys  assume  the  ultimate  responsibility  for  legal  work  but  they  often  obtain  assistance.  Paralegals  assume 
this  role  in  law  firms  and  perform  many  tasks  to  aid  the  legal  profession.  However,  they  are  explicitly  prohibited 
from  carrying  out  duties  considered  to  be  the  practice  of  law  (e.g.,  giving  legal  advice,  setting  legal  fees,  present¬ 
ing  court  cases). 

Project  management  skills  such  as  planning  are  used  in  helping  lawyers  prepare  for  closings,  hearings,  trials,  and 
corporate  meetings.  Communication  skills  are  used  in  preparing  written  reports  that  help  attorneys  determine  how 
cases  should  be  handled  or  drafts  for  actions  such  as  pleading,  filing  motions,  and  obtaining  affidavits. 
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Monitoring  skills  aid  paralegals  who  may  track  files  of  important  case  documents,  working  on  risk  containment 
related  to  filing  dates  and  responses  to  the  court.  Procurement  skills,  which  a  project  manager  uses,  can  also  be 
seen  from  a  paralegal  perspective  in  negotiating  terms  of  hiring  expert  witnesses  as  well  as  other  services  such  as 
acquiring  services  from  process  servers. 

Financial  skills  may  be  used  as  well,  such  as  assisting  in  preparing  tax  returns,  establishing  trust  funds,  and  plan¬ 
ning  estates  or  maintaining  financial  office  records  at  the  law  firm. 

Government,  litigation,  personal  injury,  corporate  law,  criminal  law,  employee  benefits,  intellectual  property,  labor 
law,  bankruptcy,  immigration,  family  law,  and  real  estate  are  some  of  the  many  different  law  practices  where  a 
paralegal  professional  may  use  project  management  skills. 

Software  developer 

Computer  software  developers  and  computer  programmers  design  and  develop  software.  They  apply  the  prin¬ 
ciples  of  computer  science  and  mathematics  to  create,  test,  and  evaluate  software  applications  and  systems  that 
make  computers  come  alive.  Software  is  developed  in  many  kinds  of  projects:  computer  games,  business  applica¬ 
tions,  operating  systems,  network  control  systems,  and  more.  Software  developers  us  project  management  skills 
to  develop  the  requirements  for  the  software,  identify  and  track  the  product  development  tasks,  communicate 
within  the  development  team  and  with  clients,  test  cases,  and  manage  quality,  the  schedule,  and  resources  (staff, 
equipment,  labs,  and  more). 

Science  Technicians 

Science  technicians  use  principles  and  theories  of  science  and  mathematics  to  assist  in  research  and  development 
and  help  invent  and  improve  products  and  processes.  In  their  jobs,  they  are  more  practically  oriented  than  scien¬ 
tists.  Planning  skills  project  managers  use  can  be  seen  as  science  technicians  set  up,  operate,  and  maintain  lab¬ 
oratory  instruments;  monitor  experiments;  and  observe,  calculate,  and  record  results.  Quality  is  a  factor  here  as 
it  is  in  project  management;  science  technicians  must  ensure  that  processes  are  performed  correctly,  with  proper 
proportions  of  ingredients,  for  purity  or  for  strength  and  durability. 

There  are  different  fields  in  which  science  technicians  can  apply  project  management  skills.  Agricultural  and  food 
science  technicians  test  food  and  other  agricultural  products  and  are  involved  in  food,  fiber,  and  animal  research, 
production,  and  processing.  Control  and  risk  management  are  important  here  in  executing  the  tests  and  experi¬ 
ments,  for  example,  to  improve  the  yield  and  quality  of  crops,  or  the  resistance  of  plants  and  animals  to  disease, 
insects,  or  other  hazards.  Quality  factors  are  paramount  when  food  science  technicians  conduct  tests  on  food  addi¬ 
tives  and  preservatives  to  ensure  compliance  with  government  regulations  regarding  color,  texture,  and  nutrients. 

Biological  technicians  work  with  biologists  studying  living  organisms.  Many  assist  scientists  who  conduct  med¬ 
ical  research  or  who  work  in  pharmaceutical  companies  to  help  develop  and  manufacture  medicines.  Skills  in 
scheduling,  especially  in  incubation  periods  for  the  study  of  the  impact  on  cells,  could  impact  projects,  such  as 
exploring  and  isolating  variables  for  research  in  living  organisms  and  infectious  agents.  Biotechnology  techni¬ 
cians  apply  knowledge  and  execution  skills  and  techniques  gained  from  basic  research,  including  gene  splicing 
and  recombinant  DNA,  to  product  development.  Project  management  skills  are  used  in  collaboration  and  commu¬ 
nication  among  team  members  to  record  and  understand  the  results  and  progress  toward  a  cure  or  product. 
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Other  kinds  of  technicians  are  chemical  technicians  who  may  work  in  laboratories  or  factories,  using  monitoring 
and  control  skills  in  the  way  they  collect  and  analyze  samples.  Again,  quality  assurance  is  an  important  factor  for 
most  process  technicians’  work  in  manufacturing,  testing  packaging  for  design,  ensuring  integrity  of  materials, 
and  verifying  environmental  acceptability. 

Technicians  use  a  project  management  skill  set  to  assist  in  their  initiation,  planning,  and  executing  tasks,  while 
managing  risks  with  some  measure  of  reporting  to  determine  if  their  objectives  satisfy  the  constraints  of  cost, 
schedule,  resource,  and  quality  standards  set. 


History 

Could  the  Great  Wall  of  China,  the  pyramids,  or  Stonehenge  have  been  built  without  project  management?  It  is 
possible  to  say  that  the  concept  of  project  management  has  been  around  since  the  beginning  of  history.  It  has 
enabled  leaders  to  plan  bold  and  massive  projects  and  manage  funding,  materials,  and  labor  within  a  designated 
time  frame. 

In  late  19th  century,  in  the  United  States,  large-scale  government  projects  were  the  impetus  for  making  important 
decisions  that  became  the  basis  for  project  management  methodology  such  as  the  transcontinental  railroad,  which 
began  construction  in  the  1860s.  Suddenly,  business  leaders  found  themselves  faced  with  the  daunting  task  of 
organizing  the  manual  labor  of  thousands  of  workers  and  the  processing  and  assembly  of  unprecedented  quantities 
of  raw  material. 


Figure  1.3:  MindView  Gantt  Chart,  by  Matchware  Inc 
(MindView)  (http://commons.wikimedia.org/wiki/ 
File%3AMindView-Gantt_Chart.png),  used  under  CC-BY-SA 
license  (https://creativecommons.0rg/licenses/by-sa/3.O/). 


Henry  Gantt,  studied  in  great  detail  the  order  of  operations  in  work  and  is  most  famous  for  developing  the  Gantt 
chart  in  the  1910s.  A  Gantt  chart  (Figure  1.3)  is  a  popular  type  of  bar  chart  that  illustrates  a  project  schedule  and 
has  become  a  common  technique  for  representing  the  phases  and  activities  of  a  project  so  they  can  be  understood 
by  a  wide  audience.  Although  now  a  common  charting  technique,  Gantt  charts  were  considered  revolutionary  at 
the  time  they  were  introduced.  Gantt  charts  were  employed  on  major  infrastructure  projects  in  the  United  States 
including  the  Hoover  Dam  and  the  interstate  highway  system  and  are  still  accepted  today  as  important  tools  in 
project  management. 

By  the  mid-20th  century,  projects  were  managed  on  an  ad  hoc  basis  using  mosdy  Gantt  charts  and  informal  tech¬ 
niques  and  tools.  During  that  time,  the  Manhattan  Project  was  initiated  and  its  complexity  was  only  possible 
because  of  project  management  methods.  The  Manhattan  Project  was  the  code  name  given  to  the  Allied  effort  to 
develop  the  first  nuclear  weapons  during  World  War  II.  It  involved  over  30  different  project  sites  in  the  United 
States  and  Canada,  and  thousands  of  personnel  from  the  United  States,  Canada,  and  the  U.K.  Born  out  of  a  small 
research  program  that  began  in  1939,  the  Manhattan  Project  would  eventually  employ  130,000  people,  cost  a  total 
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of  nearly  US$2  billion,  and  result  in  the  creation  of  multiple  production  and  research  sites  operated  in  secret.  The 
project  succeeded  in  developing  and  detonating  three  nuclear  weapons  in  1945. 

The  1950s  marked  the  beginning  of  the  modern  project  management  era.  Two  mathematical  project-scheduling 
models  were  developed. 

The  program  evaluation  and  review  technique  (PERT)  was  developed  by  Booz-Allen  and  Hamilton  as  part  of 
the  United  States  Navy’s  Polaris  missile  submarine  program.  PERT  is  basically  a  method  for  analyzing  the  tasks 
involved  in  completing  a  project,  especially  the  time  needed  to  complete  each  task,  the  dependencies  among  tasks, 
and  the  minimum  time  needed  to  complete  the  total  project  (Figure  1.4). 

The  critical  path  method  (CPM)  was  developed  in  a  joint  venture  by  DuPont  Corporation  and  Remington  Rand 
Corporation  for  managing  plant  maintenance  projects.  The  critical  path  determines  the  float,  or  schedule  flexibil¬ 
ity,  for  each  activity  by  calculating  the  earliest  start  date,  earliest  finish  date,  latest  start  date,  and  latest  finish  date 
for  each  activity.  The  critical  path  is  generally  the  longest  full  path  on  the  project.  Any  activity  with  a  float  time 
that  equals  zero  is  considered  a  critical  path  task.  CPM  can  help  you  figure  out  how  long  your  complex  project 
will  take  to  complete  and  which  activities  are  critical,  meaning  they  have  to  be  done  on  time  or  else  the  whole 
project  will  take  longer.  These  mathematical  techniques  quickly  spread  into  many  private  enterprises. 


Figure  1.4:  Pert  Chart  by  Jeremykemp  derivative  work:  Hazmat2 
from  Wikimedia  Commons  (http://commons.wikimedia.org/wiki/ 
File:Pert_chart_colored.svg),  in  the  Public  Domain 
(http://en.wikipedia.org/wiki/Public_domain). 


Project  management  in  its  present  form  began  to  take  root  a  few  decades  ago.  In  the  early  1960s,  industrial  and 
business  organizations  began  to  understand  the  benefits  of  organizing  work  around  projects.  They  understood  the 
critical  need  to  communicate  and  integrate  work  across  multiple  departments  and  professions. 
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2.  Project  Management  Overview 
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The  starting  point  in  discussing  how  projects  should  be  properly  managed  is  to  first  understand  what  a  project  is 
and,  just  as  importantly,  what  it  is  not. 

People  have  been  undertaking  projects  since  the  earliest  days  of  organized  human  activity.  The  hunting  parties 
of  our  prehistoric  ancestors  were  projects,  for  example;  they  were  temporary  undertakings  directed  at  the  goal  of 
obtaining  meat  for  the  community.  Large  complex  projects  have  also  been  with  us  for  a  long  time.  The  pyramids 
and  the  Great  Wall  of  China  were  in  their  day  of  roughly  the  same  dimensions  as  the  Apollo  project  to  send  men 
to  the  moon.  We  use  the  term  “project”  frequently  in  our  daily  conversations.  A  husband,  for  example  may  tell  his 
wife,  “My  main  project  for  this  weekend  is  to  straighten  out  the  garage.”  Going  hunting,  building  pyramids,  and 
fixing  faucets  all  share  certain  features  that  make  them  projects. 


Project  Attributes 

A  project  has  distinctive  attributes  that  distinguish  it  from  ongoing  work  or  business  operations.  Projects  are  tem¬ 
porary  in  nature.  They  are  not  an  everyday  business  process  and  have  definitive  start  dates  and  end  dates.  This 
characteristic  is  important  because  a  large  part  of  the  project  effort  is  dedicated  to  ensuring  that  the  project  is  com¬ 
pleted  at  the  appointed  time.  To  do  this,  schedules  are  created  showing  when  tasks  should  begin  and  end.  Projects 
can  last  minutes,  hours,  days,  weeks,  months,  or  years. 

Projects  exist  to  bring  about  a  product  or  service  that  hasn’t  existed  before.  In  this  sense,  a  project  is  unique. 
Unique  means  that  this  is  new;  this  has  never  been  done  before.  Maybe  it’s  been  done  in  a  very  similar  fashion 
before  but  never  exactly  in  this  way.  For  example,  Ford  Motor  Company  is  in  the  business  of  designing  and 
assembling  cars.  Each  model  that  Ford  designs  and  produces  can  be  considered  a  project.  The  models  differ  from 
each  other  in  their  features  and  are  marketed  to  people  with  various  needs.  An  SUV  serves  a  different  purpose 
and  clientele  than  a  luxury  car.  The  design  and  marketing  of  these  two  models  are  unique  projects.  However,  the 
actual  assembly  of  the  cars  is  considered  an  operation  (i.e.,  a  repetitive  process  that  is  followed  for  most  makes 
and  models). 

In  contrast  with  projects,  operations  are  ongoing  and  repetitive.  They  involve  work  that  is  continuous  without 
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an  ending  date  and  with  the  same  processes  repeated  to  produce  the  same  results.  The  purpose  of  operations  is 
to  keep  the  organization  functioning  while  the  purpose  of  a  project  is  to  meet  its  goals  and  conclude.  Therefore, 
operations  are  ongoing  while  projects  are  unique  and  temporary. 

A  project  is  completed  when  its  goals  and  objectives  are  accomplished.  It  is  these  goals  that  drive  the  project, 
and  all  the  planning  and  implementation  efforts  undertaken  to  achieve  them.  Sometimes  projects  end  when  it  is 
determined  that  the  goals  and  objectives  cannot  be  accomplished  or  when  the  product  or  service  of  the  project  is 
no  longer  needed  and  the  project  is  cancelled. 

Definition  of  a  Project 

There  are  many  written  definitions  of  a  project.  All  of  them  contain  the  key  elements  described  above.  For  those 
looking  for  a  formal  definition  of  a  project,  the  Project  Management  Institute  (PMI)  defines  a  project  as  a  tempo¬ 
rary  endeavor  undertaken  to  create  a  unique  product,  service,  or  result.  The  temporary  nature  of  projects  indicates 
a  definite  beginning  and  end.  The  end  is  reached  when  the  project’s  objectives  have  been  achieved  or  when  the 
project  is  terminated  because  its  objectives  will  not  or  cannot  be  met,  or  when  the  need  for  the  project  no  longer 
exists. 


Project  Characteristics 

When  considering  whether  or  not  you  have  a  project  on  your  hands,  there  are  some  things  to  keep  in  mind.  First, 
is  it  a  project  or  an  ongoing  operation?  Second,  if  it  is  a  project,  who  are  the  stakeholders?  And  third,  what  char¬ 
acteristics  distinguish  this  endeavor  as  a  project? 

Projects  have  several  characteristics: 

•  Projects  are  unique. 

•  Projects  are  temporary  in  nature  and  have  a  definite  beginning  and  ending  date. 

•  Projects  are  completed  when  the  project  goals  are  achieved  or  it’s  determined  the  project  is  no  longer 
viable. 

A  successful  project  is  one  that  meets  or  exceeds  the  expectations  of  the  stakeholders. 

Consider  the  following  scenario:  The  vice-president  (VP)  of  marketing  approaches  you  with  a  fabulous  idea. 
(Obviously  it  must  be  “fabulous”  because  he  thought  of  it.)  He  wants  to  set  up  kiosks  in  local  grocery  stores  as 
mini-offices.  These  offices  will  offer  customers  the  ability  to  sign  up  for  car  and  home  insurance  services  as  well 
as  make  their  bill  payments.  He  believes  that  the  exposure  in  grocery  stores  will  increase  awareness  of  the  com¬ 
pany’s  offerings.  He  told  you  that  senior  management  has  already  cleared  the  project,  and  he’ll  dedicate  as  many 
resources  to  this  as  he  can.  He  wants  the  new  kiosks  in  place  in  12  selected  stores  in  a  major  city  by  the  end  of  the 
year.  Finally,  he  has  assigned  you  to  head  up  this  project. 

Your  first  question  should  be,  “Is  it  a  project?”  This  may  seem  elementary,  but  confusing  projects  with  ongoing 
operations  happens  often.  Projects  are  temporary  in  nature,  have  definite  start  and  end  dates,  result  in  the  creation 
of  a  unique  product  or  service,  and  are  completed  when  their  goals  and  objectives  have  been  met  and  signed  off 
by  the  stakeholders. 
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Using  these  criteria,  let’s  examine  the  assignment  from  the  VP  of  marketing  to  determine  if  it  is  a  project: 

•  Is  it  unique?  Yes,  because  the  kiosks  don’t  exist  in  the  local  grocery  stores.  This  is  a  new  way  of  offering 
the  company’s  services  to  its  customer  base.  While  the  service  the  company  is  offering  isn’t  new,  the  way  it 
is  presenting  its  services  is. 

•  Does  the  product  have  a  limited  timeframe?  Yes,  the  start  date  of  this  project  is  today,  and  the  end  date  is 
the  end  of  next  year.  It  is  a  temporary  endeavor. 

•  Is  there  a  way  to  determine  when  the  project  is  completed?  Yes,  the  kiosks  will  be  installed  and  the  services 
will  be  offered  from  them.  Once  all  the  kiosks  are  installed  and  operating,  the  project  will  come  to  a  close. 

•  Is  there  a  way  to  determine  stakeholder  satisfaction?  Yes,  the  expectations  of  the  stakeholders  will  be  docu¬ 
mented  in  the  form  of  requirements  during  the  planning  processes.  These  requirements  will  be  compared  to 
the  finished  product  to  determine  if  it  meets  the  expectations  of  the  stakeholder. 

If  the  answer  is  yes  to  all  these  questions,  then  we  have  a  project. 


The  Process  of  Project  Management 

You’ve  determined  that  you  have  a  project.  What  now?  The  notes  you  scribbled  down  on  the  back  of  the  napkin 
at  lunch  are  a  start,  but  not  exactly  good  project  management  practice.  Too  often,  organizations  follow  Nike’s 
advice  when  it  comes  to  managing  projects  when  they  “just  do  it.”  An  assignment  is  made,  and  the  project  team 
members  jump  directly  into  the  development  of  the  product  or  service  requested.  In  the  end,  the  delivered  product 
doesn’t  meet  the  expectations  of  the  customer.  Unfortunately,  many  projects  follow  this  poorly  constructed  path, 
and  that  is  a  primary  contributor  to  a  large  percentage  of  projects  not  meeting  their  original  objectives,  as  defined 
by  performance,  schedule,  and  budget. 

In  the  United  States,  more  than  $250  billion  is  spent  each  year  on  information  technology  (IT)  application  devel¬ 
opment  in  approximately  175,000  projects.  The  Standish  Group  (a  Boston-based  leader  in  project  and  value  per¬ 
formance  research)  released  the  summary  version  of  their  2009  CHAOS  Report  that  tracks  project  failure  rates 
across  a  broad  range  of  companies  and  industries  (Figure  2.1). 


Figure  2.1:  Summary  of  2009  Standish  Group  CHAOS  report. 
Chaosreport2009  by  Merrie  Barron  &  Andrew  R.  Barron 

(http://commons.wikimedia.Org/wiki/File:Chaosreport2009.jpg) 
used  under  CC-BY  license  (https://creativecommons.org/licenses/ 
by/3.0/). 


Tim  Johnson,  chairman  of  the  Standish  Group,  has  stated  that  “this  year’s  results  show  a  marked  decrease  in  pro¬ 
ject  success  rates,  with  32%  of  all  projects  succeeding  which  are  delivered  on  time,  on  budget,  with  required  fea¬ 
tures  and  functions,  44%  were  challenged-which  are  late,  over  budget,  and/or  with  less  than  the  required  features 
and  functions  and  24%  failed  which  are  cancelled  prior  to  completion  or  delivered  and  never  used.” 

When  are  companies  going  to  stop  wasting  billions  of  dollars  on  failed  projects?  The  vast  majority  of  this  waste 
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is  completely  avoidable:  simply  get  the  right  business  needs  (requirements)  understood  early  in  the  process  and 
ensure  that  project  management  techniques  are  applied  and  followed,  and  the  project  activities  are  monitored. 

Applying  good  project  management  discipline  is  the  way  to  help  reduce  the  risks.  Having  good  project  manage¬ 
ment  skills  does  not  completely  eliminate  problems,  risks,  or  surprises.  The  value  of  good  project  management  is 
that  you  have  standard  processes  in  place  to  deal  with  all  contingencies. 

Project  management  is  the  application  of  knowledge,  skills,  tools,  and  techniques  applied  to  project  activities  in 
order  to  meet  the  project  requirements.  Project  management  is  a  process  that  includes  planning,  putting  the  project 
plan  into  action,  and  measuring  progress  and  performance. 

Managing  a  project  includes  identifying  your  project’s  requirements  and  writing  down  what  everyone  needs  from 
the  project.  What  are  the  objectives  for  your  project?  When  everyone  understands  the  goal,  it’s  much  easier  to 
keep  them  all  on  the  right  path.  Make  sure  you  set  goals  that  everyone  agrees  on  to  avoid  team  conflicts  later  on. 
Understanding  and  addressing  the  needs  of  everyone  affected  by  the  project  means  the  end  result  of  your  project 
is  far  more  likely  to  satisfy  your  stakeholders.  Last  but  not  least,  as  project  manager,  you  will  also  be  balancing 
the  many  competing  project  constraints. 

On  any  project,  you  will  have  a  number  of  project  constraints  that  are  competing  for  your  attention.  They  are  cost, 
scope,  quality,  risk,  resources,  and  time. 

•  Cost  is  the  budget  approved  for  the  project  including  all  necessary  expenses  needed  to  deliver  the  project. 
Within  organizations,  project  managers  have  to  balance  between  not  running  out  of  money  and  not  under¬ 
spending  because  many  projects  receive  funds  or  grants  that  have  contract  clauses  with  a  “use  it  or  lose  it” 
approach  to  project  funds.  Poorly  executed  budget  plans  can  result  in  a  last-minute  rush  to  spend  the  allo¬ 
cated  funds.  For  virtually  all  projects,  cost  is  ultimately  a  limiting  constraint;  few  projects  can  go  over  bud¬ 
get  without  eventually  requiring  a  corrective  action. 

•  Scope  is  what  the  project  is  trying  to  achieve,  ft  entails  all  the  work  involved  in  delivering  the  project  out¬ 
comes  and  the  processes  used  to  produce  them,  ft  is  the  reason  and  the  purpose  of  the  project. 

•  Quality  is  a  combination  of  the  standards  and  criteria  to  which  the  project’s  products  must  be  delivered  for 
them  to  perform  effectively.  The  product  must  perform  to  provide  the  functionality  expected,  solve  the  iden¬ 
tified  problem,  and  deliver  the  benefit  and  value  expected,  ft  must  also  meet  other  performance  require¬ 
ments,  or  service  levels,  such  as  availability,  reliability,  and  maintainability,  and  have  acceptable  finish  and 
polish.  Quality  on  a  project  is  controlled  through  quality  assurance  (QA),  which  is  the  process  of  evaluating 
overall  project  performance  on  a  regular  basis  to  provide  confidence  that  the  project  will  satisfy  the  relevant 
quality  standards. 

•  Risk  is  defined  by  potential  external  events  that  will  have  a  negative  impact  on  your  project  if  they  occur. 
Risk  refers  to  the  combination  of  the  probability  the  event  will  occur  and  the  impact  on  the  project  if  the 
event  occurs.  If  the  combination  of  the  probability  of  the  occurrence  and  the  impact  on  the  project  is  too 
high,  you  should  identify  the  potential  event  as  a  risk  and  put  a  proactive  plan  in  place  to  manage  the  risk. 

•  Resources  are  required  to  carry  out  the  project  tasks.  They  can  be  people,  equipment,  facilities,  funding,  or 
anything  else  capable  of  definition  (usually  other  than  labor)  required  for  the  completion  of  a  project  activ¬ 
ity- 
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•  Time  is  defined  as  the  time  to  complete  the  project.  Time  is  often  the  most  frequent  project  oversight  in 
developing  projects.  This  is  reflected  in  missed  deadlines  and  incomplete  deliverables.  Proper  control  of  the 
schedule  requires  the  careful  identification  of  tasks  to  be  performed  and  accurate  estimations  of  their  dura¬ 
tions,  the  sequence  in  which  they  are  going  to  be  done,  and  how  people  and  other  resources  are  to  be  allo¬ 
cated.  Any  schedule  should  take  into  account  vacations  and  holidays. 

You  may  have  heard  of  the  term  “triple  constraint,”  which  traditionally  consisted  of  only  time,  cost,  and  scope. 
These  are  the  primary  competing  project  constraints  that  you  have  to  be  most  aware  of.  The  triple  constraint  is 
illustrated  in  the  form  of  a  triangle  to  visualize  the  project  work  and  see  the  relationship  between  the  scope/qual¬ 
ity,  schedule/time,  and  cost/resource  (Figure  2.2). 


In  this  triangle,  each  side  represents  one  of  the  constraints  (or 
related  constraints)  wherein  any  changes  to  any  one  side  cause  a 
change  in  the  other  sides.  The  best  projects  have  a  perfectly 
balanced  triangle.  Maintaining  this  balance  is  difficult  because 
projects  are  prone  to  change.  For  example,  if  scope  increases, 
cost  and  time  may  increase  disproportionately.  Alternatively,  if 
the  amount  of  money  you  have  for  your  project  decreases,  you 
may  be  able  to  do  as  much,  but  your  time  may  increase.  Figure 
2.2:  A  schematic  of  the  triple  constraint  triangle. 

The  triad  constraints  by  John  M.  Kennedy  T. 
(http://commons.wikimedia.org/wiki/ 

File:The_triad_constraints.jpg)  used  under  CC-BY-SA  license 
(https://creativecommons.Org/licenses/by-sa/3.0/). 


Your  project  may  have  additional  constraints  that  you  must  face,  and  as  the  project  manager,  you  have  to  balance 
the  needs  of  these  constraints  against  the  needs  of  the  stakeholders  and  your  project  goals.  For  instance,  if  your 
sponsor  wants  to  add  functionality  to  the  original  scope,  you  will  very  likely  need  more  money  to  finish  the  pro¬ 
ject,  or  if  they  cut  the  budget,  you  will  have  to  reduce  the  quality  of  your  scope,  and  if  you  don’t  get  the  appro¬ 
priate  resources  to  work  on  your  project  tasks,  you  will  have  to  extend  your  schedule  because  the  resources  you 
have  take  much  longer  to  finish  the  work. 

You  get  the  idea;  the  constraints  are  all  dependent  on  each  other.  Think  of  all  of  these  constraints  as  the  classic 
carnival  game  of  Whac-a-mole  (Figure  2.3).  Each  time  you  try  to  push  one  mole  back  in  the  hole,  another  one 
pops  out.  The  best  advice  is  to  rely  on  your  project  team  to  keep  these  moles  in  place. 
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Figure  2.3:  Whac-a-mole.  Go  to  www.dorneypark.com/public/ 
online  fun/mole. cfm  to  play  Whac-a-mole. 
whack-a-mole  by  sakura  (https://www.flickr.com/photos/ 
sa_ku_ra/18984918/sizes/o/)  used  under  CC-BY-SA  license 

(https://creativecommons.Org/licenses/by-sa/2.0/). 


Here  is  an  example  of  a  project  that  cut  quality  because  the  project  costs  were  fixed.  The  P-36  oil  platform  (Figure 
2.4)  was  the  largest  footing  production  platform  in  the  world  capable  of  processing  180,000  barrels  of  oil  per  day 
and  5.2  million  cubic  meters  of  gas  per  day.  Located  in  the  Roncador  Field,  Campos  Basin,  Brazil,  the  P-36  was 
operated  by  Petrobras. 


Figure  2.4.:  The  Petrobras  P-36  oil  platform. 

P36  No  010  by  Richard  Collinson  (https://www.flickr.com/ 
photos/richard_collinson/2083526793/sizes/o/)  used  under 
CC-BY-ND  license  (https://creativecommons.org/licenses/by-nd/ 

2.0/). 

In  March  2001,  the  P-36  was  producing  around  84,000  barrels  of  oil  and  1.3  million  cubic  meters  of  gas  per  day 
when  it  became  destabilized  by  two  explosions  and  subsequently  sank  in  3,900  feet  of  water  with  1,650  short  tons 
of  crude  oil  remaining  on  board,  killing  11  people.  The  sinking  is  attributed  to  a  complete  failure  in  quality  assur¬ 
ance,  and  pressure  for  increased  production  led  to  corners  being  cut  on  safety  procedures.  It  is  listed  as  one  of  the 
most  expensive  accidents  with  a  price  tag  of  $515,000,000. 

The  following  quotes  are  from  a  Petrobras  executive,  citing  the  benefits  of  cutting  quality  assurance  and  inspec¬ 
tion  costs  on  the  project. 

“Petrobras  has  established  new  global  benchmarks  for  the  generation  of  exceptional  shareholder  wealth  through  an 
aggressive  and  innovative  program  of  cost  cutting  on  its  P36  production  facility.” 

“Conventional  constraints  have  been  successfully  challenged  and  replaced  with  new  paradigms  appropriate  to  the  global¬ 
ized  corporate  market  place.” 

“Elimination  of  these  unnecessary  straitjackets  has  empowered  the  project’s  suppliers  and  contractors  to  propose  highly 
economical  solutions,  with  the  win-win  bonus  of  enhanced  profitability  margins  for  themselves.” 

“The  P36  platform  shows  the  shape  of  things  to  come  in  the  unregulated  global  market  economy  of  the  21st  century.” 

The  dynamic  trade-offs  between  the  project  constraint  values  have  been  humorously  and  accurately  described  in 
Figure  2.10. 


16  •  PROJECT  MANAGEMENT 


"  Wc  can  do  GOOD.  Ql'ICK  and  CHEAP  work. 

1.  GOOD  QUICK  work  won't  be  CHEAP. 

2.  GOOD  CHEAP  wo*  wont  be  QUICK. 

3.  QUICK  CHEAP  wo*  wont  be  GOOD." 


Figure  2.5:  A  sign  seen  at  an  automotive  repair  shop. 
Illustration  from  Barron  &  Barron  Project  Management  for 
Scientists  and  Engineers. 

Source:  http://cnx.org/content/m31508/ 
latest/?collection=collll20/1.4 


Project  Management  Expertise 

In  order  for  you,  as  the  project  manager,  to  manage  the  competing  project  constraints  and  the  project  as  a  whole, 
there  are  some  areas  of  expertise  you  should  bring  to  the  project  team  (Figure  2.11).  They  are  knowledge  of  the 
application  area  and  the  standards  and  regulations  in  your  industry,  understanding  of  the  project  environment, 
general  management  knowledge  and  skills,  and  interpersonal  skills.  It  should  be  noted  that  industry  expertise  is 
not  in  a  certain  field  but  the  expertise  to  run  the  project.  So  while  knowledge  of  the  type  of  industry  is  important, 
you  will  have  a  project  team  supporting  you  in  this  endeavor.  For  example,  if  you  are  managing  a  project  that 
is  building  an  oil  platform,  you  would  not  be  expected  to  have  a  detailed  understanding  of  the  engineering  since 
your  team  will  have  mechanical  and  civil  engineers  who  will  provide  the  appropriate  expertise;  however,  it  would 
definitely  help  if  you  understood  this  type  of  work. 

Let’s  take  a  look  at  each  of  these  areas  in  more  detail. 

Application  knowledge 

By  standards,  we  mean  guidelines  or  preferred  approaches  that  are  not  necessarily  mandatory.  In  contrast,  when 
referring  to  regulations  we  mean  mandatory  rules  that  must  be  followed,  such  as  government-imposed  require¬ 
ments  through  laws.  It  should  go  without  saying  that  as  a  professional,  you’re  required  to  follow  all  applicable 
laws  and  rules  that  apply  to  your  industry,  organization,  or  project.  Every  industry  has  standards  and  regulations. 
Knowing  which  ones  affect  your  project  before  you  begin  work  will  not  only  help  the  project  to  unfold  smoothly, 
but  will  also  allow  for  effective  risk  analysis. 

Application  knowledge,  standards  &  regulations 
Understanding  the  project  environment 
Management  knowledge  &  skills 
Interpersonal  skills 


Figure  2.6:  Areas  of  expertise  that  a  project  manager  should  bring 
to  the  project  team. 

Table  from  Barron  &  Barron  Project  Management  for  Scientists 
and  Engineers, 

Source :  http ://cnx. org/ content/ collll20/1.4/ 


Some  projects  require  specific  skills  in  certain  application  areas.  Application  areas  are  made  up  of  categories  of 
projects  that  have  common  elements.  They  can  be  defined  by  industry  group  (pharmaceutical,  financial,  etc.), 
department  (accounting,  marketing,  legal,  etc.),  technology  (software  development,  engineering,  etc),  or  man¬ 
agement  specialties  (procurement,  research  and  development,  etc.).  These  application  areas  are  usually  concerned 
with  disciplines,  regulations,  and  the  specific  needs  of  the  project,  the  customer,  or  the  industry.  For  example, 
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most  government  agencies  have  specific  procurement  rules  that  apply  to  their  projects  that  wouldn’t  be  applicable 
in  the  construction  industry.  The  pharmaceutical  industry  is  interested  in  regulations  set  forth  by  government  reg¬ 
ulators,  whereas  the  automotive  industry  has  little  or  no  concern  for  either  of  these  types  of  regulations.  You  need 
to  stay  up-to-date  regarding  your  industry  so  that  you  can  apply  your  knowledge  effectively.  Today’s  fast-paced 
advances  can  leave  you  behind  fairly  quickly  if  you  don’t  stay  abreast  of  current  trends. 

Having  some  level  of  experience  in  the  application  area  you’re  working  in  will  give  you  an  advantage  when  it 
comes  to  project  management.  While  you  can  call  in  experts  who  have  the  application  area  knowledge,  it  doesn’t 
hurt  for  you  to  understand  the  specific  aspects  of  the  application  areas  of  your  project. 


Understanding  the  Project  Environment 

There  are  many  factors  that  need  to  be  understood  within  your  project  environment  (Figure  2.12).  At  one  level, 
you  need  to  think  in  terms  of  the  cultural  and  social  environments  (i.e.,  people,  demographics,  and  education). 
The  international  and  political  environment  is  where  you  need  to  understand  about  different  countries’  cultural 
influences.  Then  we  move  to  the  physical  environment;  here  we  think  about  time  zones.  Think  about  different 
countries  and  how  differently  your  project  will  be  executed  whether  it  is  just  in  your  country  or  if  it  involves  an 
international  project  team  that  is  distributed  throughout  the  world  in  five  different  countries. 


Project  Environment 

Cultural 

Social 

International 

Political 

Physical 

Figure  2.7:  The  important  factors  to  consider  within  the  project 
environment. 

Table  from  Barron  &  Barron  Project  Management  for  Scientists 
and  Engineers,  Source:  http://cnx.Org/content/collll20/l.4/ 


Of  all  the  factors,  the  physical  ones  are  the  easiest  to  understand,  and  it  is  the  cultural  and  international  factors 
that  are  often  misunderstood  or  ignored.  How  we  deal  with  clients,  customers,  or  project  members  from  other 
countries  can  be  critical  to  the  success  of  the  project.  For  example,  the  culture  of  the  United  States  values  accom¬ 
plishments  and  individualism.  Americans  tend  to  be  informal  and  call  each  other  by  first  names,  even  if  having 
just  met.  Europeans  tend  to  be  more  formal,  using  surnames  instead  of  first  names  in  a  business  setting,  even  if 
they  know  each  other  well.  In  addition,  their  communication  style  is  more  formal  than  in  the  United  States,  and 
while  they  tend  to  value  individualism,  they  also  value  history,  hierarchy,  and  loyalty.  The  Japanese,  on  the  other 
hand,  tend  to  communicate  indirectly  and  consider  themselves  part  of  a  group,  not  as  individuals.  The  Japanese 
value  hard  work  and  success,  as  most  of  us  do. 

How  a  product  is  received  can  be  very  dependent  on  the  international  cultural  differences.  For  example,  in  the 
f 990s,  when  many  large  American  and  European  telecommunications  companies  were  cultivating  new  markets  in 
Asia,  their  customer’s  cultural  differences  often  produced  unexpected  situations.  Western  companies  planned  their 
telephone  systems  to  work  the  same  way  in  Asia  as  they  did  in  Europe  and  the  United  States.  But  the  protocol 
of  conversation  was  different.  Call-waiting,  a  popular  feature  in  the  West,  is  considered  impolite  in  some  parts  of 
Asia.  This  cultural  blunder  could  have  been  avoided  had  the  team  captured  the  project  environment  requirements 
and  involved  the  customer. 

It  is  often  the  simplest  things  that  can  cause  trouble  since,  unsurprisingly,  in  different  countries,  people  do  things 
differently.  One  of  the  most  notorious  examples  of  this  is  also  one  of  the  most  simple:  date  formats.  What  day 
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and  month  is  2/8/2009?  Of  course  it  depends  where  you  come  from;  in  North  America  it  is  February  8th  while 
in  Europe  (and  much  of  the  rest  of  the  world)  it  is  2nd  August.  Clearly,  when  schedules  and  deadlines  are  being 
defined  it  is  important  that  everyone  is  clear  on  the  format  used. 

The  diversity  of  practices  and  cultures  and  its  impact  on  products  in  general  and  on  software  in  particular  goes 
well  beyond  the  date  issue.  You  may  be  managing  a  project  to  create  a  new  website  for  a  company  that  sells  prod¬ 
ucts  worldwide.  There  are  language  and  presentation  style  issues  to  take  into  consideration;  converting  the  site 
into  different  languages  isn’t  enough,  ft  is  obvious  that  you  need  to  ensure  the  translation  is  correct;  however,  the 
presentation  layer  will  have  its  own  set  of  requirements  for  different  cultures.  The  left  side  of  a  website  may  be 
the  first  focus  of  attention  for  a  Canadian;  the  right  side  would  be  the  initial  focus  for  anyone  from  the  Middle 
East,  as  both  Arabic  and  Hebrew  are  written  from  right  to  left.  Colors  also  have  different  meanings  in  different 
cultures.  White,  which  is  a  sign  of  purity  in  North  America  (e.g.,  a  bride’s  wedding  dress),  and  thus  would  be  a 
favored  background  color  in  North  America,  signifies  death  in  Japan  (e.g.,  a  burial  shroud).  Table  2.1  summarizes 
different  meanings  of  common  colors. 


Color 

United  States 

China 

Japan 

Egypt 

France 

Red 

Danger,  stop 

Happiness 

Anger,  danger 

Death 

Aristocracy 

Blue 

Sadness,  melancholy 

Heavens,  clouds 

Villainy 

Virtue,  faith,  truth 

Freedom,  peace 

Green 

Novice,  apprentice 

Ming  dynasty,  heavens 

Future,  youth,  energy 

Fertility,  strength 

Criminality 

Yellow 

Cowardice 

Birth,  wealth 

Grace,  nobility 

Happiness,  prosperity 

Temporary 

White 

Purity 

Death,  purity 

Death 

Joy 

Naturality 

Table  2.1:  The  meaning  of  colors  in  various  cultures. 

Adapted  from  P.  Russo  and  S.  Boor,  How  Fluent  is  Your  Interface?  Designing  for  International  Users,  Proceedings  of  the  INTERACT  ’93 
and  CHI  ’93,  Association  for  Computing  Machinery,  Inc.  (1993).  Table  from  Barron  &  Barron  Project  Management  for  Scientists  and 
Engineers,  Source:  http://cnx.Org/content/collll20/l.4/ 

Project  managers  in  multicultural  projects  must  appreciate  the  culture  dimensions  and  try  to  learn  relevant  cus¬ 
toms,  courtesies,  and  business  protocols  before  taking  responsibility  for  managing  an  international  project.  A  pro¬ 
ject  manager  must  take  into  consideration  these  various  cultural  influences  and  how  they  may  affect  the  project’s 
completion,  schedule,  scope,  and  cost. 

Management  Knowledge  and  Skills 

As  the  project  manager,  you  have  to  rely  on  your  project  management  knowledge  and  your  general  management 
skills.  Here,  we  are  thinking  of  items  like  your  ability  to  plan  the  project,  execute  it  properly,  and  of  course  con¬ 
trol  it  and  bring  it  to  a  successful  conclusion,  along  with  your  ability  to  guide  the  project  team  to  achieve  project 
objectives  and  balance  project  constraints. 

There  is  more  to  project  management  than  just  getting  the  work  done.  Inherent  in  the  process  of  project  manage¬ 
ment  are  the  general  management  skills  that  allow  the  project  manager  to  complete  the  project  with  some  level 
of  efficiency  and  control.  In  some  respects,  managing  a  project  is  similar  to  running  a  business:  there  are  risk  and 
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rewards,  finance  and  accounting  activities,  human  resource  issues,  time  management,  stress  management,  and  a 
purpose  for  the  project  to  exist.  Generai  management  skills  are  needed  in  every  project. 

Interpersonal  Skills 

Last  but  not  least  you  also  have  to  bring  the  ability  into  the  project  to  manage  personal  relationships  and  deal  with 
personnel  issues  as  they  arise.  Here  were  talking  about  your  interpersonal  skills  as  shown  in  Figure  2.13. 


Communication 


Project  managers  spend  90%  of  their  time  communicating.  Therefore  they  must  be  good  communicators,  promot¬ 
ing  clear,  unambiguous  exchange  of  information.  As  a  project  manager,  it  is  your  job  to  keep  a  number  of  people 
well  informed.  It  is  essential  that  your  project  staff  know  what  is  expected  of  them:  what  they  have  to  do,  when 
they  have  to  do  it,  and  what  budget  and  time  constraints  and  quality  specifications  they  are  working  toward.  If 
project  staff  members  do  not  know  what  their  tasks  are,  or  how  to  accomplish  them,  then  the  entire  project  will 
grind  to  a  halt.  If  you  do  not  know  what  the  project  staff  is  (or  often  is  not)  doing,  then  you  will  be  unable  to  mon¬ 
itor  project  progress.  Finally,  if  you  are  uncertain  of  what  the  customer  expects  of  you,  then  the  project  will  not 
even  get  off  the  ground.  Project  communication  can  thus  be  summed  up  as  knowing  “who  needs  what  information 
and  when”  and  making  sure  they  have  it. 


Interpersonal  Skills 

Communication 

Influence 

Leadership 

Motivation 

Negotiation 

Problem  solving 

Figure  2.8:  Interpersonal  skills  required  of  a  project  manager. 
Table  from  Barron  &  Barron  Project  Management  for  Scientists 
and  Engineers,  Source:  http://cnx.Org/content/collll20/l.4/ 


All  projects  require  sound  communication  plans,  but  not  all  projects  will  have  the  same  types  of  communication  or 
the  same  methods  for  distributing  the  information.  For  example,  will  information  be  distributed  via  mail  or  email, 
is  there  a  shared  website,  or  are  face-to-face  meetings  required?  The  communication  management  plan  documents 
how  the  communication  needs  of  the  stakeholders  will  be  met,  including  the  types  of  information  that  will  be 
communicated,  who  will  communicate  them,  and  who  will  receive  them;  the  methods  used  to  communicate;  the 
timing  and  frequency  of  communication;  the  method  for  updating  the  plan  as  the  project  progresses,  including  the 
escalation  process;  and  a  glossary  of  common  terms. 

Influence 

Project  management  is  about  getting  things  done.  Every  organization  is  different  in  its  policies,  modes  of  opera¬ 
tions,  and  underlying  culture.  There  are  political  alliances,  differing  motivations,  conflicting  interests,  and  power 
struggles.  A  project  manager  must  understand  all  of  the  unspoken  influences  at  work  within  an  organization. 

Leadership 

Leadership  is  the  ability  to  motivate  and  inspire  individuals  to  work  toward  expected  results.  Leaders  inspire 
vision  and  rally  people  around  common  goals.  A  good  project  manager  can  motivate  and  inspire  the  project  team 
to  see  the  vision  and  value  of  the  project.  The  project  manager  as  a  leader  can  inspire  the  project  team  to  find  a 
solution  to  overcome  perceived  obstacles  to  get  the  work  done. 
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Motivation 

Motivation  helps  people  work  more  efficiently  and  produce  better  results.  Motivation  is  a  constant  process  that 
the  project  manager  must  guide  to  help  the  team  move  toward  completion  with  passion  and  a  profound  reason 
to  complete  the  work.  Motivating  the  team  is  accomplished  by  using  a  variety  of  team-building  techniques  and 
exercises.  Team  building  is  simply  getting  a  diverse  group  of  people  to  work  together  in  the  most  efficient  and 
effective  manner  possible.  This  may  involve  management  events  as  well  as  individual  actions  designed  to  improve 
team  performance. 

Recognition  and  rewards  are  an  important  part  of  team  motivations.  They  are  formal  ways  of  recognizing  and  pro¬ 
moting  desirable  behavior  and  are  most  effective  when  carried  out  by  the  management  team  and  the  project  man¬ 
ager.  Consider  individual  preferences  and  cultural  differences  when  using  rewards  and  recognition.  Some  people 
don’t  like  to  be  recognized  in  front  of  a  group;  others  thrive  on  it. 

Negotiation 

Project  managers  must  negotiate  for  the  good  of  the  project.  In  any  project,  the  project  manager,  the  project  spon¬ 
sor,  and  the  project  team  will  have  to  negotiate  with  stakeholders,  vendors,  and  customers  to  reach  a  level  of 
agreement  acceptable  to  all  parties  involved  in  the  negotiation  process. 

Problem  Solving 

Problem  solving  is  the  ability  to  understand  the  heart  of  a  problem,  look  for  a  viable  solution,  and  then  make  a 
decision  to  implement  that  solution.  The  starting  point  for  problem  solving  is  problem  definition.  Problem  defini¬ 
tion  is  the  ability  to  understand  the  cause  and  effect  of  the  problem;  this  centers  on  root-cause  analysis.  If  a  project 
manager  treats  only  the  symptoms  of  a  problem  rather  than  its  cause,  the  symptoms  will  perpetuate  and  continue 
through  the  project  life.  Even  worse,  treating  a  symptom  may  result  in  a  greater  problem.  For  example,  increas¬ 
ing  the  ampere  rating  of  a  fuse  in  your  car  because  the  old  one  keeps  blowing  does  not  solve  the  problem  of  an 
electrical  short  that  could  result  in  a  fire.  Root-cause  analysis  looks  beyond  the  immediate  symptoms  to  the  cause 
of  the  symptoms,  which  then  affords  opportunities  for  solutions.  Once  the  root  of  a  problem  has  been  identified,  a 
decision  must  be  made  to  effectively  address  the  problem. 

Solutions  can  be  presented  from  vendors,  the  project  team,  the  project  manager,  or  various  stakeholders.  A  viable 
solution  focuses  on  more  than  just  the  problem;  it  looks  at  the  cause  and  effect  of  the  solution  itself.  In  addition, 
a  timely  decision  is  needed  or  the  window  of  opportunity  may  pass  and  then  a  new  decision  will  be  needed  to 
address  the  problem.  As  in  most  cases,  the  worst  thing  you  can  do  is  nothing. 

All  of  these  interpersonal  skills  will  be  used  in  all  areas  of  project  management.  Start  practicing  now  because  it’s 
guaranteed  that  you’ll  need  these  skills  on  your  next  project. 
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The  project  manager  and  project  team  have  one  shared  goal:  to  carry  out  the  work  of  the  project  for  the  purpose  of 
meeting  the  project’s  objectives.  Every  project  has  a  beginning,  a  middle  period  during  which  activities  move  the 
project  toward  completion,  and  an  ending  (either  successful  or  unsuccessful).  A  standard  project  typically  has  the 
following  four  major  phases  (each  with  its  own  agenda  of  tasks  and  issues):  initiation,  planning,  implementation, 
and  closure.  Taken  together,  these  phases  represent  the  path  a  project  takes  from  the  beginning  to  its  end  and  are 
generally  referred  to  as  the  project  “life  cycle.” 


Initiation  Phase 

During  the  first  of  these  phases,  the  initiation  phase,  the  project  objective  or  need  is  identified;  this  can  be  a  busi¬ 
ness  problem  or  opportunity.  An  appropriate  response  to  the  need  is  documented  in  a  business  case  with  recom¬ 
mended  solution  options.  A  feasibility  study  is  conducted  to  investigate  whether  each  option  addresses  the  project 
objective  and  a  final  recommended  solution  is  determined.  Issues  of  feasibility  (“can  we  do  the  project?”)  and 
justification  (“should  we  do  the  project?”)  are  addressed. 

Once  the  recommended  solution  is  approved,  a  project  is  initiated  to  deliver  the  approved  solution  and  a  project 
manager  is  appointed.  The  major  deliverables  and  the  participating  work  groups  are  identified,  and  the  project 
team  begins  to  take  shape.  Approval  is  then  sought  by  the  project  manager  to  move  onto  the  detailed  planning 
phase. 


Planning  Phase 

The  next  phase,  the  planning  phase,  is  where  the  project  solution  is  further  developed  in  as  much  detail  as  possible 
and  the  steps  necessary  to  meet  the  project’s  objective  are  planned.  In  this  step,  the  team  identifies  all  of  the  work 
to  be  done.  The  project’s  tasks  and  resource  requirements  are  identified,  along  with  the  strategy  for  producing 
them.  This  is  also  referred  to  as  “scope  management.”  A  project  plan  is  created  outlining  the  activities,  tasks, 
dependencies,  and  timeframes.  The  project  manager  coordinates  the  preparation  of  a  project  budget  by  providing 
cost  estimates  for  the  labor,  equipment,  and  materials  costs.  The  budget  is  used  to  monitor  and  control  cost  expen¬ 
ditures  during  project  implementation. 
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Once  the  project  team  has  identified  the  work,  prepared  the  schedule,  and  estimated  the  costs,  the  three  funda¬ 
mental  components  of  the  planning  process  are  complete.  This  is  an  excellent  time  to  identify  and  try  to  deal  with 
anything  that  might  pose  a  threat  to  the  successful  completion  of  the  project.  This  is  called  risk  management.  In 
risk  management,  “high-threat”  potential  problems  are  identified  along  with  the  action  that  is  to  be  taken  on  each 
high-threat  potential  problem,  either  to  reduce  the  probability  that  the  problem  will  occur  or  to  reduce  the  impact 
on  the  project  if  it  does  occur.  This  is  also  a  good  time  to  identify  all  project  stakeholders  and  establish  a  com¬ 
munication  plan  describing  the  information  needed  and  the  delivery  method  to  be  used  to  keep  the  stakeholders 
informed. 

Finally,  you  will  want  to  document  a  quality  plan,  providing  quality  targets,  assurance,  and  control  measures, 
along  with  an  acceptance  plan,  listing  the  criteria  to  be  met  to  gain  customer  acceptance.  At  this  point,  the  project 
would  have  been  planned  in  detail  and  is  ready  to  be  executed. 


Implementation  (Execution)  Phase 

During  the  third  phase,  the  implementation  phase,  the  project  plan  is  put  into  motion  and  the  work  of  the  project 
is  performed.  It  is  important  to  maintain  control  and  communicate  as  needed  during  implementation.  Progress  is 
continuously  monitored  and  appropriate  adjustments  are  made  and  recorded  as  variances  from  the  original  plan. 
In  any  project,  a  project  manager  spends  most  of  the  time  in  this  step.  During  project  implementation,  people 
are  carrying  out  the  tasks,  and  progress  information  is  being  reported  through  regular  team  meetings.  The  pro¬ 
ject  manager  uses  this  information  to  maintain  control  over  the  direction  of  the  project  by  comparing  the  progress 
reports  with  the  project  plan  to  measure  the  performance  of  the  project  activities  and  take  corrective  action  as 
needed.  The  first  course  of  action  should  always  be  to  bring  the  project  back  on  course  (i.e.,  to  return  it  to  the 
original  plan).  If  that  cannot  happen,  the  team  should  record  variations  from  the  original  plan  and  record  and  pub¬ 
lish  modifications  to  the  plan.  Throughout  this  step,  project  sponsors  and  other  key  stakeholders  should  be  kept 
informed  of  the  project’s  status  according  to  the  agreed-on  frequency  and  format  of  communication.  The  plan 
should  be  updated  and  published  on  a  regular  basis. 

Status  reports  should  always  emphasize  the  anticipated  end  point  in  terms  of  cost,  schedule,  and  quality  of  deliv¬ 
erables.  Each  project  deliverable  produced  should  be  reviewed  for  quality  and  measured  against  the  acceptance 
criteria.  Once  all  of  the  deliverables  have  been  produced  and  the  customer  has  accepted  the  final  solution,  the 
project  is  ready  for  closure. 


Closing  Phase 

During  the  final  closure,  or  completion  phase,  the  emphasis  is  on  releasing  the  final  deliverables  to  the  customer, 
handing  over  project  documentation  to  the  business,  terminating  supplier  contracts,  releasing  project  resources, 
and  communicating  the  closure  of  the  project  to  all  stakeholders.  The  last  remaining  step  is  to  conduct  lessons- 
learned  studies  to  examine  what  went  well  and  what  didn’t.  Through  this  type  of  analysis,  the  wisdom  of  experi¬ 
ence  is  transferred  back  to  the  project  organization,  which  will  help  future  project  teams. 

Example:  Project  Phases  on  a  Large  Multinational  Project 

A  U.S.  construction  company  won  a  contract  to  design  and  build  the  first  copper  mine  in  northern  Argentina. 
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There  was  no  existing  infrastructure  for  either  the  mining  industry  or  large  construction  projects  in  this  part  of 
South  America.  During  the  initiation  phase  of  the  project,  the  project  manager  focused  on  defining  and  finding  a 
project  leadership  team  with  the  knowledge,  skills,  and  experience  to  manage  a  large  complex  project  in  a  remote 
area  of  the  globe.  The  project  team  set  up  three  offices.  One  was  in  Chile,  where  large  mining  construction  project 
infrastructure  existed.  The  other  two  were  in  Argentina.  One  was  in  Buenos  Aries  to  establish  relationships  and 
Argentinian  expertise,  and  the  second  was  in  Catamarca — the  largest  town  close  to  the  mine  site.  With  offices 
in  place,  the  project  start-up  team  began  developing  procedures  for  getting  work  done,  acquiring  the  appropriate 
permits,  and  developing  relationships  with  Chilean  and  Argentine  partners. 

During  the  planning  phase,  the  project  team  developed  an  integrated  project  schedule  that  coordinated  the  activi¬ 
ties  of  the  design,  procurement,  and  construction  teams.  The  project  controls  team  also  developed  a  detailed  bud¬ 
get  that  enabled  the  project  team  to  track  project  expenditures  against  the  expected  expenses.  The  project  design 
team  built  on  the  conceptual  design  and  developed  detailed  drawings  for  use  by  the  procurement  team.  The  pro¬ 
curement  team  used  the  drawings  to  begin  ordering  equipment  and  materials  for  the  construction  team;  develop 
labor  projections;  refine  the  construction  schedule;  and  set  up  the  construction  site.  Although  planning  is  a  never- 
ending  process  on  a  project,  the  planning  phase  focused  on  developing  sufficient  details  to  allow  various  parts  of 
the  project  team  to  coordinate  their  work  and  allow  the  project  management  team  to  make  priority  decisions. 

The  implementation  phase  represents  the  work  done  to  meet  the  requirements  of  the  scope  of  work  and  fulfill  the 
charter.  During  the  implementation  phase,  the  project  team  accomplished  the  work  defined  in  the  plan  and  made 
adjustments  when  the  project  factors  changed.  Equipment  and  materials  were  delivered  to  the  work  site,  labor  was 
hired  and  trained,  a  construction  site  was  built,  and  all  the  construction  activities,  from  the  arrival  of  the  first  dozer 
to  the  installation  of  the  final  light  switch,  were  accomplished. 

The  closeout  phase  included  turning  over  the  newly  constructed  plant  to  the  operations  team  of  the  client.  A  punch 
list  of  a  few  remaining  construction  items  was  developed  and  those  items  completed.  The  office  in  Catamarca  was 
closed,  the  office  in  Buenos  Aries  archived  all  the  project  documents,  and  the  Chilean  office  was  already  working 
on  the  next  project.  The  accounting  books  were  reconciled  and  closed,  final  reports  written  and  distributed,  and 
the  project  manager  started  on  a  new  project. 


Attribution 

This  chapter  of  Project  Management  is  a  derivative  copy  of  Project  Management  by  Merrie  Barron  and  Andrew 
Barron  licensed  under  Creative  Commons  Attribution  3.0  Unported  and  Project  Management  From  Simple  to 
Complex  by  Russel  Darnall,  John  Preston,  Eastern  Michigan  University  licensed  under  Creative  Commons  Attri¬ 
bution  3.0  Unported. 


4.  Framework  for  Project  Management 


ADRIENNE  WATT 


Many  different  professions  contribute  to  the  theory  and  practice  of  project  management.  Engineers  and  architects 
have  been  managing  major  projects  since  pre-history.  Since  approximately  the  1960s,  there  have  been  efforts  to 
professionalize  the  practice  of  project  management  as  a  specialization  of  its  own.  There  are  many  active  debates 
around  this:  Should  project  management  be  a  profession  in  the  same  way  as  engineering,  accounting,  and  med¬ 
icine?  These  have  professional  associations  that  certify  who  is  legally  allowed  to  use  the  job  title,  and  who  can 
legally  practice  the  profession.  They  also  provide  a  level  of  assurance  of  quality  and  discipline  members  who 
behave  inappropriately.  Another  ongoing  debate  is:  How  much  industry  knowledge  is  required  of  a  seasoned  pro¬ 
ject  manager?  How  easily  can  a  project  manager  from  one  industry,  say,  IT,  transition  to  another  industry  such  as 
hospitality? 

There  are  two  major  organizations  with  worldwide  impact  on  the  practice  of  project  management:  the  Project 
Management  Institute  (PM1),  with  world  headquarters  in  the  United  States,  and  the  International  Project  Manage¬ 
ment  Association  (IPMA),  with  world  headquarters  in  Switzerland.  This  textbook  takes  an  approach  that  is  closer 
to  the  PMI  approach  (http://www.pmi.org).  More  details  are  included  in  this  chapter,  along  with  a  section  on  the 
project  management  office. 


Project  Management  Institute  Overview 

Five  volunteers  founded  the  Project  Management  Institute  (PMI)  in  1969.  Their  initial  goal  was  to  establish  an 
organization  where  members  could  share  their  experiences  in  project  management  and  discuss  issues.  Today,  PMI 
is  a  non-profit  project  management  professional  association  and  the  most  widely  recognized  organization  in  terms 
of  promoting  project  management  best  practices.  PMI  was  formed  to  serve  the  interests  of  the  project  management 
industry.  The  premise  of  PMI  is  that  the  tools  and  techniques  of  project  management  are  common  even  among 
the  widespread  application  of  projects  from  the  software  to  the  construction  industry.  PMI  first  began  offering  the 
Project  Management  Professional  (PMP)  certification  exam  in  1984.  Although  it  took  a  while  for  people  to  take 
notice,  now  more  than  590,000  individuals  around  the  world  hold  the  PMP  designation. 

To  help  keep  project  management  terms  and  concepts  clear  and  consistent,  PMI  introduced  the  book  A  Guide  to 
the  Project  Management  Body  of  Knowledge  (PMBOK  Guide)  in  1987.  It  was  updated  it  in  1996,  2000,  2004, 
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2009,  and  most  recently  in  2013  as  the  fifth  edition.  At  present,  there  are  more  than  one  million  copies  of  the 
PMBOK  Guide  in  circulation.  The  highly  regarded  Institute  of  Electrical  and  Electronics  Engineers  (IEEE)  has 
adopted  it  as  their  project  management  standard.  In  1999  PMI  was  accredited  as  an  American  National  Stan¬ 
dards  Institute  (ANSI)  standards  developer  and  also  has  the  distinction  of  being  the  first  organization  to  have  its 
certification  program  attain  International  Organization  for  Standardization  (ISO)  9001  recognition.  In  2008,  the 
organization  reported  more  than  260,000  members  in  over  171  countries.  PMI  has  its  headquarters  in  Pennsylva¬ 
nia,  United  States,  and  also  has  offices  in  Washington,  DC,  and  in  Canada,  Mexico,  and  China,  as  well  as  having 
regional  service  centers  in  Singapore,  Brussels  (Belgium),  and  New  Delhi  (India).  Recently,  an  office  was  opened 
in  Mumbai  (India). 

Because  of  the  importance  of  projects,  the  discipline  of  project  management  has  evolved  into  a  working  body  of 
knowledge  known  as  PMBOK  -  Project  Management  Body  of  Knowledge.  The  PMI  is  responsible  for  develop¬ 
ing  and  promoting  PMBOK.  PMI  also  administers  a  professional  certification  program  for  project  managers,  the 
PMP.  So  if  you  want  to  get  grounded  in  project  management,  PMBOK  is  the  place  to  start,  and  if  you  want  to 
make  project  management  your  profession,  then  you  should  consider  becoming  a  PMP. 

So  what  is  PMBOK? 

PMBOK  is  the  fundamental  knowledge  you  need  for  managing  a  project,  categorized  into  10  knowledge  areas: 

1.  Managing  integration:  Projects  have  all  types  of  activities  going  on  and  there  is  a  need  to  keep  the 
“whole”  thing  moving  collectively  -  integrating  all  of  the  dynamics  that  take  place.  Managing  integration  is 
about  developing  the  project  charter,  scope  statement,  and  plan  to  direct,  manage,  monitor,  and  control  pro¬ 
ject  change. 

2.  Managing  scope:  Projects  need  to  have  a  defined  parameter  or  scope,  and  this  must  be  broken  down  and 
managed  through  a  work  breakdown  structure  or  WBS.  Managing  scope  is  about  planning,  definition, 

WBS  creation,  verification,  and  control. 

3.  Managing  time/schedule:  Projects  have  a  definite  beginning  and  a  definite  ending  date.  Therefore,  there 
is  a  need  to  manage  the  budgeted  time  according  to  a  project  schedule.  Managing  time/schedule  is  about 
definition,  sequencing,  resource  and  duration  estimating,  schedule  development,  and  schedule  control. 

4.  Managing  costs:  Projects  consume  resources,  and  therefore,  there  is  a  need  to  manage  the  investment 
with  the  realization  of  creating  value  (i.e.,  the  benefits  derived  exceed  the  amount  spent).  Managing  costs  is 
about  resource  planning,  cost  estimating,  budgeting,  and  control. 

5.  Managing  quality:  Projects  involve  specific  deliverables  or  work  products.  These  deliverables  need  to 
meet  project  objectives  and  performance  standards.  Managing  quality  is  about  quality  planning,  quality 
assurance,  and  quality  control. 

6.  Managing  human  resources:  Projects  consist  of  teams  and  you  need  to  manage  project  team(s)  during 
the  life  cycle  of  the  project.  Finding  the  right  people,  managing  their  outputs,  and  keeping  them  on  schedule 
is  a  big  part  of  managing  a  project.  Managing  human  resources  is  about  human  resources  planning,  hiring, 
and  developing  and  managing  a  project  team. 

7.  Managing  communication:  Projects  invariably  touch  lots  of  people,  not  just  the  end  users  (customers) 
who  benefit  directly  from  the  project  outcomes.  This  can  include  project  participants,  managers  who  over- 
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see  the  project,  and  external  stakeholders  who  have  an  interest  in  the  success  of  the  project.  Managing 
communication  is  about  communications  planning,  information  distribution,  performance  reporting,  and 
stakeholder  management. 

8.  Managing  risk:  Projects  are  a  discovery-driven  process,  often  uncovering  new  customer  needs  and  iden¬ 
tifying  critical  issues  not  previously  disclosed.  Projects  also  encounter  unexpected  events,  such  as  project 
team  members  resigning,  budgeted  resources  suddenly  changing,  the  organization  becoming  unstable,  and 
newer  technologies  being  introduced.  There  is  a  real  need  to  properly  identify  various  risks  and  manage 
these  risks.  Managing  risk  is  about  risk  planning  and  identification,  risk  analysis  (qualitative  and  quantita¬ 
tive),  risk  response  (action)  planning,  and  risk  monitoring  and  control. 

9.  Managing  procurement:  Projects  procure  the  services  of  outside  vendors  and  contractors,  including  the 
purchase  of  equipment.  There  is  a  need  to  manage  how  vendors  are  selected  and  managed  within  the  project 
life  cycle.  Managing  procurement  is  about  acquisition  and  contracting  plans,  sellers’  responses  and  selec¬ 
tions,  contract  administration,  and  contract  closure. 

10.  Managing  stakeholders:  Every  project  impacts  people  and  organizations  and  is  impacted  by  people 
and  organizations.  Identifying  these  stakeholders  early,  and  as  they  arise  and  change  throughout  the  project, 
is  a  key  success  factor.  Managing  stakeholders  is  about  identifying  stakeholders,  their  interest  level,  and 
their  potential  to  influence  the  project;  and  managing  and  controlling  the  relationships  and  communications 
between  stakeholders  and  the  project. 

This  is  the  big  framework  for  managing  projects  and  if  you  want  to  be  effective  in  managing  projects,  then  you 
need  to  be  effective  in  managing  each  of  the  10  knowledge  areas  that  make  up  PMBOK  (see  Figure  4.1) 


Figure  4.1:  PM  Star  Model  suggested  by  GeekDisplaced 
(http :  //commons  .wikimedia,  org/wiki/ 
File:PM_StarModel_suggested.jpg)  used  under 
CC-BY-SA  license  (http://creativecommons.org/licenses/ 
by-sa/3.0/deed.en). 


Certification  in  project  management  is  available  from  the  PMI,  PRINCE2,  ITIL,  Critical  Chain,  and  others.  Agile 
project  management  methodologies  (Scrum,  extreme  programming,  Lean  Six  Sigma,  others)  also  have  certifica¬ 
tions. 


Introduction  to  the  Project  Management  Knowledge  Areas 

As  discussed  above,  projects  are  divided  into  components,  and  a  project  manager  must  be  knowledgeable  in  each 
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area.  Each  of  these  areas  of  knowledge  will  be  explored  in  more  depth  in  subsequent  chapters.  For  now,  lets  look 
at  them  in  a  little  more  detail  to  prepare  you  for  the  chapters  that  follow. 

Project  Start-Up  and  Integration 

The  start-up  of  a  project  is  similar  to  the  start-up  of  a  new  organization.  The  project  leader  develops  the  project 
infrastructure  used  to  design  and  execute  the  project.  The  project  management  team  must  develop  alignment 
among  the  major  stakeholders — those  who  have  a  share  or  interest — on  the  project  during  the  early  phases  or 
definition  phases  of  the  project.  The  project  manager  will  conduct  one  or  more  kickoff  meetings  or  alignment  ses¬ 
sions  to  bring  the  various  parties  of  the  project  together  and  begin  the  project  team  building  required  to  operate 
efficiently  during  the  project. 

During  project  start-up,  the  project  management  team  refines  the  scope  of  work  and  develops  a  preliminary  sched¬ 
ule  and  conceptual  budget.  The  project  team  builds  a  plan  for  executing  the  project  based  on  the  project  profile. 
The  plan  for  developing  and  tracking  the  detailed  schedule,  the  procurement  plan,  and  the  plan  for  building  the 
budget  and  estimating  and  tracking  costs  are  developed  during  the  start-up.  The  plans  for  information  technology, 
communication,  and  tracking  client  satisfaction  are  also  all  developed  during  the  start-up  phase  of  the  project. 

Flowcharts,  diagrams,  and  responsibility  matrices  are  tools  to  capture  the  work  processes  associated  with  execut¬ 
ing  the  project  plan.  The  first  draft  of  the  project  procedures  manual  captures  the  historic  and  intuitional  knowl¬ 
edge  that  team  members  bring  to  the  project.  The  development  and  review  of  these  procedures  and  work  processes 
contribute  to  the  development  of  the  organizational  structure  of  the  project. 

This  is  typically  an  exciting  time  on  a  project  where  all  things  are  possible.  The  project  management  team  is  work¬ 
ing  many  hours  developing  the  initial  plan,  staffing  the  project,  and  building  relationships  with  the  client.  The  pro¬ 
ject  manager  sets  the  tone  of  the  project  and  sets  expectations  for  each  of  the  project  team  members.  The  project 
start-up  phase  on  complex  projects  can  be  chaotic,  and  until  plans  are  developed,  the  project  manager  becomes  the 
source  of  information  and  direction.  The  project  manager  creates  an  environment  that  encourages  team  members 
to  fully  engage  in  the  project  and  encourages  innovative  approaches  to  developing  the  project  plan. 

Project  Scope 

The  project  scope  is  a  document  that  defines  the  parameters — factors  that  define  a  system  and  determine  its  behav¬ 
ior — of  the  project,  what  work  is  done  within  the  boundaries  of  the  project,  and  the  work  that  is  outside  the  project 
boundaries.  The  scope  of  work  (SOW)  is  typically  a  written  document  that  defines  what  work  will  be  accom¬ 
plished  by  the  end  of  the  project — the  deliverables  of  the  project.  The  project  scope  defines  what  will  be  done, 
and  the  project  execution  plan  defines  how  the  work  will  be  accomplished. 

No  template  works  for  all  projects.  Some  projects  have  a  very  detailed  scope  of  work,  and  some  have  a  short 
summary  document.  The  quality  of  the  scope  is  measured  by  the  ability  of  the  project  manager  and  project  stake¬ 
holders  to  develop  and  maintain  a  common  understanding  of  what  products  or  services  the  project  will  deliver. 
The  size  and  detail  of  the  project  scope  is  related  to  the  complexity  profile  of  the  project.  A  more  complex  project 
often  requires  a  more  detailed  and  comprehensive  scope  document. 


According  to  the  PM1,  the  scope  statement  should  include  the  following: 
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•  Description  of  the  scope 

•  Product  acceptance  criteria 

•  Project  deliverables 

•  Project  exclusions 

•  Project  constraints 

•  Project  assumptions 

The  scope  document  is  the  basis  for  agreement  by  all  parties.  A  clear  project  scope  document  is  also  critical  to 
managing  change  on  a  project.  Since  the  project  scope  reflects  what  work  will  be  accomplished  on  the  project,  any 
change  in  expectations  that  is  not  captured  and  documented  creates  the  opportunity  for  confusion.  One  of  the  most 
common  trends  on  projects  is  the  incremental  expansion  in  the  project  scope.  This  trend  is  labeled  “scope  creep.” 
Scope  creep  threatens  the  success  of  a  project  because  the  small  increases  in  scope  require  additional  resources 
that  were  not  in  the  plan.  Increasing  the  scope  of  the  project  is  a  common  occurrence,  and  adjustments  are  made 
to  the  project  budget  and  schedule  to  account  for  these  changes.  Scope  creep  occurs  when  these  changes  are  not 
recognized  or  not  managed.  The  ability  of  a  project  manager  to  identify  potential  changes  is  often  related  to  the 
quality  of  the  scope  documents. 

Events  do  occur  that  require  the  scope  of  the  project  to  change.  Changes  in  the  marketplace  may  require  change  in 
a  product  design  or  the  timing  of  the  product  delivery.  Changes  in  the  client’s  management  team  or  the  financial 
health  of  the  client  may  also  result  in  changes  in  the  project  scope.  Changes  in  the  project  schedule,  budget,  or 
product  quality  will  have  an  effect  on  the  project  plan.  Generally,  the  later  in  the  project  the  change  occurs,  the 
greater  the  increase  to  the  project  costs.  Establishing  a  change  management  system  for  the  project  that  captures 
changes  to  the  project  scope  and  assures  that  these  changes  are  authorized  by  the  appropriate  level  of  management 
in  the  client’s  organization  is  the  responsibility  of  the  project  manager.  The  project  manager  also  analyzes  the  cost 
and  schedule  impact  of  these  changes  and  adjusts  the  project  plan  to  reflect  the  changes  authorized  by  the  client. 
Changes  to  the  scope  can  cause  costs  to  increase  or  decrease. 

Project  Schedule  and  Time  Management 

The  definition  of  project  success  often  includes  completing  the  project  on  time.  The  development  and  manage¬ 
ment  of  a  project  schedule  that  will  complete  the  project  on  time  is  a  primary  responsibility  of  the  project  manager, 
and  completing  the  project  on  time  requires  the  development  of  a  realistic  plan  and  the  effective  management  of 
the  plan.  On  smaller  projects,  project  managers  may  lead  the  development  of  the  project  plan  and  build  a  schedule 
to  meet  that  plan.  On  larger  and  more  complex  projects,  a  project  controls  team  that  focuses  on  both  costs  and 
schedule  planning  and  controlling  functions  will  assist  the  project  management  team  in  developing  the  plan  and 
tracking  progress  against  the  plan. 

To  develop  the  project  schedule,  the  project  team  does  an  analysis  of  the  project  scope,  contract,  and  other  infor¬ 
mation  that  helps  the  team  define  the  project  deliverables.  Based  on  this  information,  the  project  team  develops  a 
milestone  schedule.  The  milestone  schedule  establishes  key  dates  throughout  the  life  of  a  project  that  must  be  met 
for  the  project  to  finish  on  time.  The  key  dates  are  often  established  to  meet  contractual  obligations  or  established 
intervals  that  will  reflect  appropriate  progress  for  the  project.  For  less  complex  projects,  a  milestone  schedule 
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may  be  sufficient  for  tracking  the  progress  of  the  project.  For  more  complex  projects,  a  more  detailed  schedule  is 
required. 

To  develop  a  more  detailed  schedule,  the  project  team  first  develops  a  work  breakdown  structure  (WBS) — a 
description  of  tasks  arranged  in  layers  of  detail.  Although  the  project  scope  is  the  primary  document  for  devel¬ 
oping  the  WBS,  the  WBS  incorporates  all  project  deliverables  and  reflects  any  documents  or  information  that 
clarifies  the  project  deliverables.  From  the  WBS,  a  project  plan  is  developed.  The  project  plan  lists  the  activities 
that  are  needed  to  accomplish  the  work  identified  in  the  WBS.  The  more  detailed  the  WBS,  the  more  activities 
that  are  identified  to  accomplish  the  work. 

After  the  project  team  identifies  the  activities,  the  team  sequences  the  activities  according  to  the  order  in  which 
the  activities  are  to  be  accomplished.  An  outcome  from  the  work  process  is  the  project  logic  diagram.  The  logic 
diagram  represents  the  logical  sequence  of  the  activities  needed  to  complete  the  project.  The  next  step  in  the  plan¬ 
ning  process  is  to  develop  an  estimation  of  the  time  it  will  take  to  accomplish  each  activity  or  the  activity  duration. 
Some  activities  must  be  done  sequentially,  and  some  activities  can  be  done  concurrently.  The  planning  process 
creates  a  project  schedule  by  scheduling  activities  in  a  way  that  effectively  and  efficiently  uses  project  resources 
and  completes  the  project  in  the  shortest  time. 

On  larger  projects,  several  paths  are  created  that  represent  a  sequence  of  activities  from  the  beginning  to  the  end 
of  the  project.  The  longest  path  to  the  completion  of  the  project  is  the  critical  path.  If  the  critical  path  takes  less 
time  than  is  allowed  by  the  client  to  complete  the  project,  the  project  has  a  positive  total  float  or  project  slack.  If 
the  client’s  project  completion  date  precedes  the  calculated  critical  path  end  date,  the  project  has  a  negative  float. 
Understanding  and  managing  activities  on  the  critical  path  is  an  important  project  management  skill. 

To  successfully  manage  a  project,  the  project  manager  must  also  know  how  to  accelerate  a  schedule  to  compensate 
for  unanticipated  events  that  delay  critical  activities.  Compressing — crashing — the  schedule  is  a  term  used  to 
describe  the  techniques  used  to  shorten  the  project  schedule.  During  the  life  of  the  project,  scheduling  conflicts 
often  occur,  and  the  project  manager  is  responsible  for  reducing  these  conflicts  while  maintaining  project  quality 
and  meeting  cost  goals. 

Project  Costs 

The  definition  of  project  success  often  includes  completing  the  project  within  budget.  Developing  and  controlling 
a  project  budget  that  will  accomplish  the  project  objectives  is  a  critical  project  management  skill.  Although  clients 
expect  the  project  to  be  executed  efficiently,  cost  pressures  vary  on  projects.  On  some  projects,  the  project  com¬ 
pletion  or  end  date  is  the  largest  contributor  to  the  project  complexity.  The  development  of  a  new  drug  to  address 
a  critical  health  issue,  the  production  of  a  new  product  that  will  generate  critical  cash  flow  for  a  company,  and 
the  competitive  advantage  for  a  company  to  be  first  in  the  marketplace  with  a  new  technology  are  examples  of 
projects  with  schedule  pressures  that  override  project  costs. 

The  accuracy  of  the  project  budget  is  related  to  the  amount  of  information  known  by  the  project  team.  In  the 
early  stages  of  the  project,  the  amount  of  information  needed  to  develop  a  detailed  budget  is  often  missing.  To 
address  the  lack  of  information,  the  project  team  develops  different  levels  of  project  budget  estimates.  The  con¬ 
ceptual  estimate  (or  “ballpark  estimate”)  is  developed  with  the  least  amount  of  knowledge.  The  major  input  into 
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the  conceptual  estimate  is  expert  knowledge  or  past  experience.  A  project  manager  who  has  executed  a  similar 
project  in  the  past  can  use  those  costs  to  estimate  the  costs  of  the  current  project. 

When  more  information  is  known,  the  project  team  can  develop  a  rough  order  of  magnitude  (ROM)  estimate. 
Additional  information  such  as  the  approximate  square  feet  of  a  building,  the  production  capacity  of  a  plant,  and 
the  approximate  number  of  hours  needed  to  develop  a  software  program  can  provide  a  basis  for  providing  a  ROM 
estimate.  After  a  project  design  is  more  complete,  a  project  detailed  estimate  can  be  developed.  For  example, 
when  the  project  team  knows  the  number  of  rooms,  the  type  of  materials,  and  the  building  location  of  a  home,  they 
can  provide  a  detailed  estimate.  A  detailed  estimate  is  not  a  bid. 

The  cost  of  the  project  is  tracked  relative  to  the  progress  of  the  work  and  the  estimate  for  accomplishing  that  work. 
Based  on  the  cost  estimate,  the  cost  of  the  work  performed  is  compared  against  the  cost  budgeted  for  that  work. 
If  the  cost  is  significantly  higher  or  lower,  the  project  team  explores  reasons  for  the  difference  between  expected 
costs  and  actual  costs. 

Project  costs  may  deviate  from  the  budget  because  the  prices  in  the  marketplace  were  different  from  what  was 
expected.  For  example,  the  estimated  costs  for  lumber  on  a  housing  project  may  be  higher  than  budgeted  or  the 
hourly  cost  for  labor  may  be  lower  than  budgeted.  Project  costs  may  also  deviate  based  on  project  performance. 
For  example,  a  project  team  estimated  that  the  steel  design  for  a  bridge  over  a  river  would  take  800  labor  hours, 
but  846  hours  were  actually  expended.  The  project  team  captures  the  deviation  between  costs  budgeted  for  work 
and  the  actual  cost  for  work,  revises  the  estimate  as  needed,  and  takes  corrective  action  if  the  deviation  appears  to 
reflect  a  trend. 

The  project  manager  is  responsible  for  assuring  that  the  project  team  develops  cost  estimates  based  on  the  best 
information  available  and  revises  those  estimates  as  new  or  better  information  becomes  available.  The  project 
manager  is  also  responsible  for  tracking  costs  against  the  budget  and  conducting  an  analysis  when  project  costs 
deviate  significantly  from  the  project  estimate.  The  project  manager  then  takes  appropriate  corrective  action  to 
ensure  that  project  performance  matches  the  revised  project  plan. 

Project  Quality 

Project  quality  focuses  on  the  end  product  or  service  deliverables  that  reflect  the  purpose  of  the  project.  The  pro¬ 
ject  manager  is  responsible  for  developing  a  project  execution  approach  that  provides  for  a  clear  understanding 
of  the  expected  project  deliverables  and  the  quality  specifications.  The  project  manager  of  a  housing  construction 
project  not  only  needs  to  understand  which  rooms  in  the  house  will  be  carpeted  but  also  what  grade  of  carpet  is 
needed.  A  room  with  a  high  volume  of  traffic  will  need  a  high-grade  carpet. 

The  project  manager  is  responsible  for  developing  a  project  quality  plan  that  defines  the  quality  expectations  and 
ensures  that  the  specifications  and  expectations  are  met.  Developing  a  good  understanding  of  the  project  deliv¬ 
erables  through  documenting  specifications  and  expectations  is  critical  to  a  good  quality  plan.  The  processes  for 
ensuring  that  the  specifications  and  expectations  are  met  are  integrated  into  the  project  execution  plan.  Just  as  the 
project  budget  and  completion  dates  may  change  over  the  life  of  a  project,  the  project  specifications  may  also 
change.  Changes  in  quality  specifications  are  typically  managed  in  the  same  process  as  cost  or  schedule  changes. 
The  impact  of  the  changes  is  analyzed  for  impact  on  cost  and  schedule,  and  with  appropriate  approvals,  changes 
are  made  to  the  project  execution  plan. 
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The  PMI’s  A  Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK  Guide)  has  an  extensive  chapter 
on  project  quality  management.  The  material  found  in  this  chapter  would  be  similar  to  material  found  in  a  good 
operational  management  text. 

Although  any  of  the  quality  management  techniques  designed  to  make  incremental  improvement  to  work 
processes  can  be  applied  to  a  project  work  process,  the  character  of  a  project  (unique  and  relatively  short  in  dura¬ 
tion)  makes  small  improvements  less  attractive  on  projects.  Rework  on  projects,  as  with  manufacturing  opera¬ 
tions,  increases  the  cost  of  the  product  or  service  and  often  increases  the  time  needed  to  complete  the  reworked 
activities.  Because  of  the  duration  constraints  of  a  project,  the  development  of  the  appropriate  skills,  materials, 
and  work  processes  early  in  the  project  is  critical  to  project  success.  On  more  complex  projects,  time  is  allocated 
to  developing  a  plan  to  understand  and  develop  the  appropriate  levels  of  skills  and  work  processes. 

Project  management  organizations  that  execute  several  similar  types  of  projects  may  find  process  improvement 
tools  useful  in  identifying  and  improving  the  baseline  processes  used  on  their  projects.  Process  improvement  tools 
may  also  be  helpful  in  identifying  cost  and  schedule  improvement  opportunities.  Opportunities  for  improvement 
must  be  found  quickly  to  influence  project  performance.  The  investment  in  time  and  resources  to  find  improve¬ 
ments  is  greatest  during  the  early  stages  of  the  project,  when  the  project  is  in  the  planning  stages.  During  later 
project  stages,  as  pressures  to  meet  project  schedule  goals  increase,  the  culture  of  the  project  is  less  conducive  to 
making  changes  in  work  processes. 

Another  opportunity  for  applying  process  improvement  tools  is  on  projects  that  have  repetitive  processes.  A  hous¬ 
ing  contractor  that  is  building  several  identical  houses  may  benefit  from  evaluating  work  processes  in  the  first  few 
houses  to  explore  the  opportunities  available  to  improve  the  work  processes.  The  investment  of  $1,000  in  a  work 
process  that  saves  $200  per  house  is  a  good  investment  as  long  as  the  contractor  is  building  more  than  five  houses. 

Project  Team:  Human  Resources  and  Communications 

Staffing  the  project  with  the  right  skills,  at  the  right  place,  and  at  the  right  time  is  an  important  responsibility  of  the 
project  management  team.  The  project  usually  has  two  types  of  team  members:  functional  managers  and  process 
managers.  The  functional  managers  and  team  focus  on  the  technology  of  the  project.  On  a  construction  project, 
the  functional  managers  would  include  the  engineering  manager  and  construction  superintendents.  On  a  training 
project,  the  functional  manager  would  include  the  professional  trainers;  on  an  information  technology  project, 
the  software  development  managers  would  be  functional  managers.  The  project  management  team  also  includes 
project  process  managers.  The  project  controls  team  would  include  process  managers  who  have  expertise  in  esti¬ 
mating,  cost  tracking,  planning,  and  scheduling.  The  project  manager  needs  functional  and  process  expertise  to 
plan  and  execute  a  successful  project. 

Because  projects  are  temporary,  the  staffing  plan  for  a  project  typically  reflects  both  the  long-term  goals  of  skilled 
team  members  needed  for  the  project  and  short-term  commitment  that  reflects  the  nature  of  the  project.  Exact 
start  and  end  dates  for  team  members  are  often  negotiated  to  best  meet  the  needs  of  individuals  and  the  project. 
The  staffing  plan  is  also  determined  by  the  different  phases  of  the  project.  Team  members  needed  in  the  early  or 
conceptual  phases  of  the  project  are  often  not  needed  during  the  later  phases  or  project  closeout  phases.  Team 
members  needed  during  the  implementation  phase  are  often  not  needed  during  the  conceptual  or  closeout  phases. 
Each  phase  has  staffing  requirements,  and  the  staffing  of  a  complex  project  requires  detailed  planning  to  have  the 
right  skills,  at  the  right  place,  at  the  right  time. 
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Typically  a  core  project  management  team  is  dedicated  to  the  project  from  start-up  to  closeout.  This  core  team 
would  include  members  of  the  project  management  team:  project  manager,  project  controls,  project  procurement, 
and  key  members  of  the  function  management  or  experts  in  the  technology  of  the  project.  Although  longer  pro¬ 
jects  may  experience  more  team  turnover  than  shorter  projects,  it  is  important  on  all  projects  to  have  team  mem¬ 
bers  who  can  provide  continuity  through  the  project  phases. 

For  example,  on  a  large  commercial  building  project,  the  civil  engineering  team  that  designs  the  site  work  where 
the  building  will  be  constructed  would  make  their  largest  contribution  during  the  early  phases  of  the  design.  The 
civil  engineering  lead  would  bring  on  different  civil  engineering  specialties  as  they  were  needed.  As  the  civil  engi¬ 
neering  work  is  completed  and  the  structural  engineering  is  well  underway,  a  large  portion  of  the  civil  engineers 
would  be  released  from  the  project.  The  functional  managers,  the  engineering  manager,  and  civil  engineering  lead 
would  provide  expertise  during  the  entire  length  of  the  project,  addressing  technical  questions  that  may  arise  and 
addressing  change  requests. 

Project  team  members  can  be  assigned  to  the  project  from  a  number  of  different  sources.  The  organization  that 
charters  the  project  can  assign  talented  managers  and  staff  from  functional  units  within  the  organization,  con¬ 
tract  with  individuals  or  agencies  to  staff  positions  on  the  project,  temporarily  hire  staff  for  the  project,  or  use 
any  combination  of  these  staffing  options.  This  staffing  approach  allows  the  project  manager  to  create  the  project 
organizational  culture.  Some  project  cultures  are  more  structured  and  detail  oriented,  and  some  are  less  structured 
with  less  formal  roles  and  communication  requirements.  The  type  of  culture  the  project  manager  creates  depends 
greatly  on  the  type  of  project. 

Communications 

Completing  a  complex  project  successfully  requires  teamwork,  and  teamwork  requires  good  communication 
among  team  members.  If  those  team  members  work  in  the  same  building,  they  can  arrange  regular  meetings,  sim¬ 
ply  stop  by  each  other’s  office  space  to  get  a  quick  answer,  or  even  discuss  a  project  informally  at  other  office 
functions.  Many  complex  projects  in  today’s  global  economy  involve  team  members  from  widely  separated  loca¬ 
tions,  and  the  types  of  meetings  that  work  within  the  same  building  are  not  possible.  Teams  that  use  electronic 
methods  of  communicating  without  face-to-face  meetings  are  called  virtual  teams. 

Communicating  can  be  divided  into  two  categories:  synchronous  and  asynchronous.  If  all  the  parties  to  the  com¬ 
munication  are  taking  part  in  the  exchange  at  the  same  time,  the  communication  is  synchronous.  A  telephone  con¬ 
ference  call  is  an  example  of  synchronous  communication.  When  the  participants  are  not  interacting  at  the  same 
time,  the  communication  is  asynchronous.  (The  letter  a  at  the  beginning  of  the  word  means  not.)  Communications 
technologies  require  a  variety  of  compatible  devices,  software,  and  service  providers,  and  communication  with  a 
global  virtual  team  can  involve  many  different  time  zones.  Establishing  effective  communications  requires  a  com¬ 
munications  plan. 

Project  Risk 

Risk  exists  on  all  projects.  The  role  of  the  project  management  team  is  to  understand  the  kinds  and  levels  of  risks 
on  the  project  and  then  to  develop  and  implement  plans  to  mitigate  these  risks.  Risk  represents  the  likelihood  that 
an  event  will  happen  during  the  life  of  the  project  that  will  negatively  affect  the  achievement  of  project  goals.  The 
type  and  amount  of  risk  varies  by  industry  type,  complexity,  and  phase  of  the  project.  The  project  risk  plan  will 
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also  reflect  the  risk  profile  of  the  project  manager  and  key  stakeholders.  People  have  different  comfort  levels  with 
risk,  and  some  members  of  the  project  team  will  be  more  risk  averse  than  others. 

The  first  step  in  developing  a  risk  management  plan  involves  identifying  potential  project  risks.  Some  risks  are 
easy  to  identify,  such  as  the  potential  for  a  damaging  storm  in  the  Caribbean,  and  some  are  less  obvious.  Many 
industries  or  companies  have  risk  checklists  developed  from  past  experience.  The  Construction  Industry  Insti¬ 
tute  published  a  100-item  risk  checklist  that  provides  examples  and  areas  of  project  risks.  No  risk  checklist  will 
include  all  potential  risks.  The  value  of  a  checklist  is  the  stimulation  of  discussion  and  thought  about  the  potential 
risks  on  a  project. 

The  project  team  analyzes  the  identified  risks  and  estimates  the  likelihood  of  the  risks  occurring.  The  team  then 
estimates  the  potential  impact  on  project  goals  if  the  event  does  occur.  The  outcome  from  this  process  is  a  pri¬ 
oritized  list  of  estimated  project  risks  with  a  value  that  represents  the  likelihood  of  occurrence  and  the  potential 
impact  on  the  project. 

The  project  team  then  develops  a  risk  mitigation  plan  that  reduces  the  likelihood  of  an  event  occurring  or  reduces 
the  impact  on  the  project  if  the  event  does  occur.  The  risk  management  plan  is  integrated  into  the  project  execu¬ 
tion  plan,  and  mitigation  activities  are  assigned  to  the  appropriate  project  team  member.  The  likelihood  that  all 
the  potential  events  identified  in  the  risk  analysis  would  occur  is  extremely  rare.  The  likelihood  that  one  or  more 
events  will  happen  is  high. 

The  project  risk  plan  reflects  the  risk  profile  of  the  project  and  balances  the  investment  of  the  mitigation  against 
the  benefit  for  the  project.  One  of  the  more  common  risk  mitigation  approaches  is  the  use  of  contingency.  Con¬ 
tingency  is  funds  set  aside  by  the  project  team  to  address  unforeseen  events.  Projects  with  a  high-risk  profile  will 
typically  have  a  large  contingency  budget.  If  the  team  knows  which  activities  have  the  highest  risk,  contingency 
can  be  allocated  to  activities  with  the  highest  risk.  When  risks  are  less  identifiable  to  specific  activities,  contin¬ 
gency  is  identified  in  a  separate  line  item.  The  plan  includes  periodic  risk-plan  reviews  during  the  life  of  the  pro¬ 
ject.  The  risk  review  evaluates  the  effectiveness  of  the  current  plan  and  explores  possible  risks  not  identified  in 
earlier  sessions. 

Project  Procurement 

The  procurement  effort  on  projects  varies  widely  and  depends  on  the  type  of  project.  Often  the  client  organization 
will  provide  procurement  services  on  less  complex  projects.  In  this  case,  the  project  team  identifies  the  materials, 
equipment,  and  supplies  needed  by  the  project  and  provides  product  specifications  and  a  detailed  delivery  sched¬ 
ule.  When  the  procurement  department  of  the  parent  organization  provides  procurement  services,  a  liaison  from 
the  project  can  help  the  procurement  team  better  understand  the  unique  requirements  of  the  project  and  the  time- 
sensitive  or  critical  items  of  the  project  schedule. 

On  larger,  more  complex  projects,  personnel  are  dedicated  to  procuring  and  managing  the  equipment,  supplies, 
and  materials  needed  by  the  project.  Because  of  the  temporary  nature  of  projects,  equipment,  supplies,  and  mate¬ 
rials  are  procured  as  part  of  the  product  of  the  project  or  for  the  execution  of  the  project.  For  example,  the  bricks 
procured  for  a  construction  project  would  be  procured  for  the  product  of  the  project,  and  the  mortar  mixer  would 
be  equipment  procured  for  the  execution  of  the  project  work.  At  the  end  of  the  project,  equipment  bought  or  rented 
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for  the  execution  of  the  work  of  the  project  are  sold,  returned  to  rental  organizations,  or  disposed  of  some  other 
way. 

More  complex  projects  will  typically  procure  through  different  procurement  and  management  methods.  Com¬ 
modities  are  common  products  that  are  purchased  based  on  the  lowest  bid.  Commodities  include  items  like  con¬ 
crete  for  building  projects,  office  supplies,  or  even  lab  equipment  for  a  research  project.  The  second  type  of 
procurement  includes  products  that  are  specified  for  the  project.  Vendors  who  can  produce  these  products  bid  for 
a  contract.  The  awarding  of  a  contract  can  include  price,  ability  to  meet  the  project  schedule,  the  fit  for  purpose 
of  the  product,  and  other  considerations  important  to  the  project.  Manufacturing  a  furnace  for  a  new  steel  mill 
would  be  provided  by  a  project  vendor.  Equipment  especially  designed  and  built  for  a  research  project  is  another 
example.  These  vendors’  performances  become  important  parts  of  the  project,  and  the  project  manager  assigns 
resources  to  coordinate  the  work  and  schedule  of  the  vendor.  The  third  procurement  approach  is  the  development 
of  one  or  more  partners.  A  design  firm  that  is  awarded  the  design  contract  for  a  major  part  of  the  steel  mill  and 
a  research  firm  that  is  conducting  critical  subparts  of  the  research  are  examples  of  potential  project  partners.  A 
partner  contributes  to  and  is  integrated  into  the  execution  plan.  Partners  perform  best  when  they  share  the  project 
vision  of  success  and  are  emotionally  invested  in  the  project.  The  project  management  team  builds  and  imple¬ 
ments  a  project  procurement  plan  that  recognizes  the  most  efficient  and  effective  procurement  approach  to  support 
the  project  schedule  and  goals. 

Project  Stakeholder  Management 

People  and  organizations  can  have  many  different  relationships  to  the  project.  Most  commonly,  these  relationships 
can  be  grouped  into  those  who  will  be  impacted  by  the  project  and  those  who  can  impact  the  project. 

A  successful  project  manager  will  identify  stakeholders  early  in  the  project.  For  each  stakeholder,  it  is  important 
to  identify  what  they  want  or  need  and  what  influence  or  power  they  have  over  the  project.  Based  on  this  infor¬ 
mation,  the  need  to  communicate  with  the  stakeholder  or  stakeholder  group  can  be  identified,  followed  by  the 
creation  of  a  stakeholder  management  plan.  A  stakeholder  register  is  used  to  identify  and  track  the  interactions 
between  the  project  and  each  stakeholder.  This  register  must  be  updated  on  a  regular  basis,  as  new  stakeholders 
can  arise  at  any  time,  and  the  needs  and  interest  levels  of  a  particular  stakeholder  may  change  through  the  course 
of  the  project. 


Table  4.1  Stakeholder  Register 
Source:  A. Watt 
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Scrum  Development  Overview 

“Scrum”  is  another  formal  project  management/product  development  methodology  and  part  of  agile  project  man¬ 
agement.  Scrum  is  a  term  from  rugby  (scrimmage)  that  means  a  way  of  restarting  a  game.  It’s  like  restarting  the 
project  efforts  every  X  weeks.  It’s  based  on  the  idea  that  you  do  not  really  know  how  to  plan  the  whole  project  up 
front,  so  you  start  and  build  empirical  data,  and  then  re-plan  and  iterate  from  there. 

Scrum  uses  sequential  sprints  for  development.  Sprints  are  like  small  project  phases  (ideally  two  to  four  weeks). 
The  idea  is  to  take  one  day  to  plan  for  what  can  be  done  now,  then  develop  what  was  planned  for,  and  demonstrate 
it  at  the  end  of  the  sprint.  Scrum  uses  a  short  daily  meeting  of  the  development  team  to  check  what  was  done  yes¬ 
terday,  what  is  planned  for  the  next  day,  and  what  if  anything  is  impeding  the  team  members  from  accomplishing 
what  they  have  committed  to.  At  the  end  of  the  sprint,  what  has  been  demonstrated  can  then  be  tested,  and  the 
next  sprint  cycle  starts. 

Scrum  methodology  defines  several  major  roles.  They  are: 

•  Product  owners:  essentially  the  business  owner  of  the  project  who  knows  the  industry,  the  market,  the  cus¬ 
tomers,  and  the  business  goals  of  the  project.  The  product  owner  must  be  intimately  involved  with  the 
Scrum  process,  especially  the  planning  and  the  demonstration  parts  of  the  sprint. 

•  Scrum  Master:  somewhat  like  a  project  manager,  but  not  exactly.  The  Scrum  Master’s  duties  are  essentially 
to  remove  barriers  that  impede  the  progress  of  the  development  team,  teach  the  product  owner  how  to  maxi¬ 
mize  return  on  investment  (ROI)  in  terms  of  development  effort,  facilitate  creativity  and  empowerment  of 
the  team,  improve  the  productivity  of  the  team,  improve  engineering  practices  and  tools,  run  daily  standup 
meetings,  track  progress,  and  ensure  the  health  of  the  team. 

•  Development  team:  self-organizing  (light-touch  leadership),  empowered  group;  they  participate  in  planning 
and  estimating  for  each  sprint,  do  the  development,  and  demonstrate  the  results  at  the  end  of  the  sprint.  It 
has  been  shown  that  the  ideal  size  for  a  development  team  is  7+1-  2.  The  development  team  can  be  broken 
into  “teamlets”  that  “swarm”  on  user  stories,  which  are  created  in  the  sprint  planning  session. 

Typically,  the  way  a  product  is  developed  is  that  there  is  a  “front  burner”  (which  has  stories/tasks  for  the  current 
sprint),  a  “back  burner”  (which  has  stories  for  the  next  sprint),  and  a  “fridge”  (which  has  stories  for  later,  as  well 
as  process  changes).  One  can  look  at  a  product  as  having  been  broken  down  like  this:  product  ->  features  ->  sto¬ 
ries  ->  tasks. 

Often  effort  estimations  are  done  using  “story  points”  (tiny  =  1  SP,  small  =  2  SP,  medium  =  4  SP,  large  =  8  SP,  big 
=  16+  SP,  unknown  =  ?  SP)  Stories  can  be  of  various  types.  User  stories  are  very  common  and  are  descriptions  of 
what  the  user  can  do  and  what  happens  as  a  result  of  different  actions  from  a  given  starting  point.  Other  types  of 
stories  are  from  these  areas:  analysis,  development,  QA,  documentation,  installation,  localization,  and  training. 

Planning  meetings  for  each  sprint  require  participation  by  the  product  owner,  the  Scrum  Master,  and  the  develop¬ 
ment  team.  In  the  planning  meeting,  they  set  the  goals  for  the  upcoming  sprint  and  select  a  subset  of  the  product 
backlog  (proposed  stories)  to  work  on.  The  development  team  decomposes  stories  to  tasks  and  estimates  them. 
The  development  team  and  product  owner  do  final  negotiations  to  determine  the  backlog  for  the  following  sprint. 
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The  Scrum  methodology  uses  metrics  to  help  with  future  planning  and  tracking  of  progress;  for  example,  “burn 
down”  -  the  number  of  hours  remaining  in  the  sprint  versus  the  time  in  days;  “velocity”  -  essentially,  the  amount 
of  effort  the  team  expends.  (After  approximately  three  sprints  with  the  same  team,  one  can  get  a  feel  for  what  the 
team  can  do  going  forward.) 

Some  caveats  about  using  Scrum  methodology:  1)  You  need  committed,  mature  developers;  2)  You  still  need  to 
do  major  requirements  definition,  some  analysis,  architecture  definition,  and  definition  of  roles  and  terms  up  front 
or  early;  3)  You  need  commitment  from  the  company  and  the  product  owner;  and  4)  It  is  best  for  products  that 
require  frequent  new  releases  or  updates,  and  less  effective  for  large,  totally  new  products  that  will  not  allow  for 
frequent  upgrades  once  they  are  released. 


The  Project  Management  Office 

Many  large  and  even  medium-sized  organizations  have  created  a  department  to  oversee  and  support  projects 
throughout  the  organization.  This  is  an  attempt  to  reduce  the  high  numbers  of  failed  projects  (see  the  Project  Man¬ 
agement  Overview  chapter.)  These  offices  are  usually  called  the  project  management  office  or  PMO. 

The  PMO  may  be  the  home  of  all  the  project  managers  in  an  organization,  or  it  may  simply  be  a  resource  for  all 
project  managers,  who  report  to  their  line  areas. 

Typical  objectives  of  a  PMO  are: 

•  Help  ensure  that  projects  are  aligned  with  organizational  objectives 

•  Provide  templates  and  procedures  for  use  by  project  managers 

•  Provide  training  and  mentorship 

•  Provide  facilitation 

•  Stay  abreast  of  the  latest  trends  in  project  management 

•  Serve  as  a  repository  for  project  reports  and  lessons  learned 

The  existence  and  role  of  PMOs  tends  to  be  somewhat  fluid.  If  a  PMO  is  created,  and  greater  success  is  not  expe¬ 
rienced  in  organizational  projects,  the  PMO  is  at  risk  of  being  disbanded  as  a  cost-saving  measure.  If  an  orga¬ 
nization  in  which  you  are  a  project  manager  or  a  project  team  member  has  a  PMO,  try  to  make  good  use  of  the 
resources  available.  If  you  are  employed  as  a  resource  person  in  a  PMO,  remember  that  your  role  is  not  to  get  in 
the  way  and  create  red  tape,  but  to  enable  and  enhance  the  success  of  project  managers  and  projects  within  the 
organization. 


Attribution 

This  chapter  of  Project  Management  is  a  derivative  copy  of  Project  Management  by  Merrie  Barron  and  Andrew 
Barron  licensed  under  Creative  Commons  Attribution  3.0  Unported  and  Project  Management  From  Simple  to 
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Complex  by  Russel  Darnall,  John  Preston,  Eastern  Michigan  University  licensed  under  Creative  Commons  Attri¬ 
bution  3.0  Unported. 


5.  Stakeholder  Management 


ADRIENNE  WATT 


A  project  is  successful  when  it  achieves  its  objectives  and  meets  or  exceeds  the  expectations  of  the  stakeholders. 
But  who  are  the  stakeholders?  Stakeholders  are  individuals  who  either  care  about  or  have  a  vested  interest  in  your 
project.  They  are  the  people  who  are  actively  involved  with  the  work  of  the  project  or  have  something  to  either 
gain  or  lose  as  a  result  of  the  project.  When  you  manage  a  project  to  add  lanes  to  a  highway,  motorists  are  stake¬ 
holders  who  are  positively  affected.  However,  you  negatively  affect  residents  who  live  near  the  highway  during 
your  project  (with  construction  noise)  and  after  your  project  with  far-reaching  implications  (increased  traffic  noise 
and  pollution). 


The  project  sponsor,  generally  an  executive  in  the  orga-  NOTE:  Key  Stakeholders  Can  make  Or 

nization  with  the  authority  to  assign  resources  and  break  the  SUCCeSS  of  a  project.  Even  if  all 
enforce  decisions  regarding  the  project,  is  a  stakeholder.  ^  de|jverab|es  afe  met  and  the 

The  customer,  subcontractors,  suppliers,  and  sometimes 
even  the  government  are  stakeholders.  The  project  man¬ 
ager,  project  team  members,  and  the  managers  from 
other  departments  in  the  organization  are  stakeholders 
as  well.  It’s  important  to  identify  all  the  stakeholders  in 
your  project  upfront.  Leaving  out  important  stakeholders  or  their  department’s  function  and  not  discovering  the 
error  until  well  into  the  project  could  be  a  project  killer. 

Figure  5.1  shows  a  sample  of  the  project  environment  featuring  the  different  kinds  of  stakeholders  involved  on  a 
typical  project.  A  study  of  this  diagram  confronts  us  with  a  couple  of  interesting  facts. 

First,  the  number  of  stakeholders  that  project  managers  must  deal  with  ensures  that  they  will  have  a  complex  job 
guiding  their  project  through  the  lifecycle.  Problems  with  any  of  these  members  can  derail  the  project. 

Second,  the  diagram  shows  that  project  managers  have  to  deal  with  people  external  to  the  organization  as  well 
as  the  internal  environment,  certainly  more  complex  than  what  a  manager  in  an  internal  environment  faces.  For 
example,  suppliers  who  are  late  in  delivering  crucial  parts  may  blow  the  project  schedule.  To  compound  the  prob- 


objectives  are  satisfied,  if  your  key 
stakeholders  aren't  happy,  nobody's 
happy. 
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lem,  project  managers  generally  have  little  or  no  direct  control  over  any  of  these  individuals. 


Figure  5.1:  Project  stakeholders. 

Illustration  from  Barron  &  Barron  Project  Management  for 
Scientists  and  Engineers, 

Source :  http ://cnx. org/content/col  11120/1.4/ 


Let’s  take  a  look  at  these  stakeholders  and  their  relationships  to  the  project  manager. 


Project  Stakeholders 

Top  Management 

Top  management  may  include  the  president  of  the  company,  vice-presidents,  directors,  division  managers,  the 
corporate  operating  committee,  and  others.  These  people  direct  the  strategy  and  development  of  the  organization. 

On  the  plus  side,  you  are  likely  to  have  top  management  support,  which  means  it  will  be  easier  to  recruit  the  best 
staff  to  carry  out  the  project,  and  acquire  needed  material  and  resources;  also  visibility  can  enhance  a  project  man¬ 
ager’s  professional  standing  in  the  company. 

On  the  minus  side,  failure  can  be  quite  dramatic  and  visible  to  all,  and  if  the  project  is  large  and  expensive  (most 
are),  the  cost  of  failure  will  be  more  substantial  than  for  a  smaller,  less  visible  project. 

Some  suggestions  in  dealing  with  top  management  are: 

•  Develop  in-depth  plans  and  major  milestones  that  must  be  approved  by  top  management  during  the  plan¬ 
ning  and  design  phases  of  the  project. 

•  Ask  top  management  associated  with  your  project  for  their  information  reporting  needs  and  frequency. 

•  Develop  a  status  reporting  methodology  to  be  distributed  on  a  scheduled  basis. 

•  Keep  them  informed  of  project  risks  and  potential  impacts  at  all  times. 

The  Project  Team 

The  project  team  is  made  up  of  those  people  dedicated  to  the  project  or  borrowed  on  a  part-time  basis.  As  project 
manager,  you  need  to  provide  leadership,  direction,  and  above  all,  the  support  to  team  members  as  they  go  about 
accomplishing  their  tasks.  Working  closely  with  the  team  to  solve  problems  can  help  you  learn  from  the  team  and 
build  rapport.  Showing  your  support  for  the  project  team  and  for  each  member  will  help  you  get  their  support  and 
cooperation. 


40  •  PROJECT  MANAGEMENT 


Here  are  some  difficulties  you  may  encounter  in  dealing  with  project  team  members: 

•  Because  project  team  members  are  borrowed  and  they  don’t  report  to  you,  their  priorities  may  be  elsewhere. 

•  They  may  be  juggling  many  projects  as  well  as  their  full-time  job  and  have  difficulty  meeting  deadlines. 

•  Personality  conflicts  may  arise.  These  may  be  caused  by  differences  in  social  style  or  values  or  they  may  be 
the  result  of  some  bad  experience  when  people  worked  together  in  the  past. 

•  You  may  find  out  about  missed  deadlines  when  it  is  too  late  to  recover. 

Managing  project  team  members  requires  interpersonal  skills.  Here  are  some  suggestions  that  can  help: 

•  Involve  team  members  in  project  planning. 

•  Arrange  to  meet  privately  and  informally  with  each  team  member  at  several  points  in  the  project,  perhaps 
for  lunch  or  coffee. 

•  Be  available  to  hear  team  members’  concerns  at  any  time. 

•  Encourage  team  members  to  pitch  in  and  help  others  when  needed. 

•  Complete  a  project  performance  review  for  team  members. 

Your  Manager 

Typically  the  boss  decides  what  the  assignment  is  and  who  can  work  with  the  project  manager  on  projects.  Keep¬ 
ing  your  manager  informed  will  help  ensure  that  you  get  the  necessary  resources  to  complete  your  project. 

If  things  go  wrong  on  a  project,  it  is  nice  to  have  an  understanding  and  supportive  boss  to  go  to  bat  for  you  if 
necessary.  By  supporting  your  manager,  you  will  find  your  manager  will  support  you  more  often. 

•  Find  out  exactly  how  your  performance  will  be  measured. 

•  When  unclear  about  directions,  ask  for  clarification. 

•  Develop  a  reporting  schedule  that  is  acceptable  to  your  boss. 

•  Communicate  frequently. 

Peers 

Peers  are  people  who  are  at  the  same  level  in  the  organization  as  you  and  may  or  may  not  be  on  the  project  team. 
These  people  will  also  have  a  vested  interest  in  the  product.  However,  they  will  have  neither  the  leadership  respon¬ 
sibilities  nor  the  accountability  for  the  success  or  failure  of  the  project  that  you  have. 

Your  relationship  with  peers  can  be  impeded  by: 

•  Inadequate  control  over  peers 

•  Political  maneuvering  or  sabotage 

•  Personality  conflicts  or  technical  conflicts 

•  Envy  because  your  peer  may  have  wanted  to  lead  the  project 
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•  Conflicting  instructions  from  your  manager  and  your  peer’s  manager 

Peer  support  is  essential.  Because  most  of  us  serve  our  self-interest  first,  use  some  investigating,  selling,  influenc¬ 
ing,  and  politicking  skills  here.  To  ensure  you  have  cooperation  and  support  from  your  peers: 

•  Get  the  support  of  your  project  sponsor  or  top  management  to  empower  you  as  the  project  manager  with  as 
much  authority  as  possible.  It’s  important  that  the  sponsor  makes  it  clear  to  the  other  team  members  that 
their  cooperation  on  project  activities  is  expected. 

•  Confront  your  peer  if  you  notice  a  behavior  that  seems  dysfunctional,  such  as  bad-mouthing  the  project. 

•  Be  explicit  in  asking  for  full  support  from  your  peers.  Arrange  for  frequent  review  meetings. 

•  Establish  goals  and  standards  of  performance  for  all  team  members. 

Resource  Managers 

Because  project  managers  are  in  the  position  of  borrowing  resources,  other  managers  control  their  resources.  So 
their  relationships  with  people  are  especially  important.  If  their  relationship  is  good,  they  may  be  able  to  consis¬ 
tently  acquire  the  best  staff  and  the  best  equipment  for  their  projects.  If  relationships  aren’t  good,  they  may  find 
themselves  not  able  to  get  good  people  or  equipment  needed  on  the  project. 

Internal  Customers 

Internal  customers  are  individuals  within  the  organization  who  are  customers  for  projects  that  meet  the  needs  of 
internal  demands.  The  customer  holds  the  power  to  accept  or  reject  your  work.  Early  in  the  relationship,  the  pro¬ 
ject  manager  will  need  to  negotiate,  clarify,  and  document  project  specifications  and  deliverables.  After  the  pro¬ 
ject  begins,  the  project  manager  must  stay  tuned  in  to  the  customer’s  concerns  and  issues  and  keep  the  customer 
informed. 

Common  stumbling  blocks  when  dealing  with  internal  customers  include: 

•  A  lack  of  clarity  about  precisely  what  the  customer  wants 

•  A  lack  of  documentation  for  what  is  wanted 

•  A  lack  of  knowledge  of  the  customer’s  organization  and  operating  characteristics 

•  Unrealistic  deadlines,  budgets,  or  specifications  requested  by  the  customer 

•  Hesitancy  of  the  customer  to  sign  off  on  the  project  or  accept  responsibility  for  decisions 

•  Changes  in  project  scope 

To  meet  the  needs  of  the  customer,  client,  or  owner,  be  sure  to  do  the  following: 

•  Learn  the  client  organization’s  buzzwords,  culture,  and  business. 

•  Clarify  all  project  requirements  and  specifications  in  a  written  agreement. 

•  Specify  a  change  procedure. 

•  Establish  the  project  manager  as  the  focal  point  of  communications  in  the  project  organization. 
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External  customer 

External  customers  are  the  customers  when  projects  could  be  marketed  to  outside  customers.  In  the  case  of  Ford 
Motor  Company,  for  example,  the  external  customers  would  be  the  buyers  of  the  automobiles.  Also  if  you  are 
managing  a  project  at  your  company  for  Ford  Motor  Company,  they  will  be  your  external  customer. 

Government 

Project  managers  working  in  certain  heavily  regulated  environments  (e.g.,  pharmaceutical,  banking,  or  military 
industries)  will  have  to  deal  with  government  regulators  and  departments.  These  can  include  all  or  some  levels  of 
government  from  municipal,  provincial,  federal,  to  international. 

Contractors,  subcontractors,  and  suppliers 

There  are  times  when  organizations  don’t  have  the  expertise  or  resources  available  in-house,  and  work  is  farmed 
out  to  contractors  or  subcontractors.  This  can  be  a  construction  management  foreman,  network  consultant,  elec¬ 
trician,  carpenter,  architect,  or  anyone  who  is  not  an  employee.  Managing  contractors  or  suppliers  requires  many 
of  the  skills  needed  to  manage  full-time  project  team  members. 

Any  number  of  problems  can  arise  with  contractors  or  subcontractors: 

•  Quality  of  the  work 

•  Cost  overruns 

•  Schedule  slippage 

Many  projects  depend  on  goods  provided  by  outside  suppliers.  This  is  true  for  example  of  construction  projects 
where  lumber,  nails,  bricks,  and  mortar  come  from  outside  suppliers.  If  the  supplied  goods  are  delivered  late  or 
are  in  short  supply  or  of  poor  quality  or  if  the  price  is  greater  than  originally  quoted,  the  project  may  suffer. 

Depending  on  the  project,  managing  contractor  and  supplier  relationships  can  consume  more  than  half  of  the  pro¬ 
ject  manager’s  time.  It  is  not  purely  intuitive;  it  involves  a  sophisticated  skill  set  that  includes  managing  conflicts, 
negotiating,  and  other  interpersonal  skills. 


Politics  of  Projects 

Many  times,  project  stakeholders  have  conflicting  interests.  It’s  the  project  manager’s  responsibility  to  understand 
these  conflicts  and  try  to  resolve  them.  It’s  also  the  project  manger’s  responsibility  to  manage  stakeholder  expec¬ 
tations.  Be  certain  to  identify  and  meet  with  all  key  stakeholders  early  in  the  project  to  understand  all  their  needs 
and  constraints. 

Project  managers  are  somewhat  like  politicians.  Typically,  they  are  not  inherently  powerful  or  capable  of  imposing 
their  will  directly  on  coworkers,  subcontractors,  and  suppliers.  Tike  politicians,  if  they  are  to  get  their  way,  they 
have  to  exercise  influence  effectively  over  others.  On  projects,  project  managers  have  direct  control  over  very  few 
things;  therefore  their  ability  to  influence  others  -  to  be  a  good  politician  -  may  be  very  important 
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Here  are  a  few  steps  a  good  project  politician  should  follow.  However,  a  good  rule  is  that  when  in  doubt,  stake¬ 
holder  conflicts  should  always  be  resolved  in  favor  of  the  customer. 

Assess  the  environment 

Identify  all  the  relevant  stakeholders.  Because  any  of  these  stakeholders  could  derail  the  project,  you  need  to  con¬ 
sider  their  particular  interest  in  the  project. 

•  Once  all  relevant  stakeholders  are  identified,  try  to  determine  where  the  power  lies. 

•  In  the  vast  cast  of  characters,  who  counts  most? 

•  Whose  actions  will  have  the  greatest  impact? 

Identify  goals 

After  determining  who  the  stakeholders  are,  identify  their  goals. 

•  What  is  it  that  drives  them? 

•  What  is  each  after? 

•  Are  there  any  hidden  agendas  or  goals  that  are  not  openly  articulated? 

•  What  are  the  goals  of  the  stakeholders  who  hold  the  power?  These  deserve  special  attention. 

Define  the  problem 

•  The  facts  that  constitute  the  problem  should  be  isolated  and  closely  examined. 

•  The  question  “What  is  the  real  situation?”  should  be  raised  over  and  over. 


Culture  of  Stakeholders 

When  project  stakeholders  do  not  share  a  common  culture,  project  management  must  adapt  its  organizations  and 
work  processes  to  cope  with  cultural  differences.  The  following  are  three  major  aspects  of  cultural  difference  that 
can  affect  a  project: 

1.  Communications 

2.  Negotiations 

3.  Decision  making 

Communication  is  perhaps  the  most  visible  manifestation  of  culture.  Project  managers  encounter  cultural  differ¬ 
ences  in  communication  in  language,  context,  and  candor. 

Language  is  clearly  the  greatest  barrier  to  communication.  When  project  stakeholders  do  not  share  the  same  lan¬ 
guage,  communication  slows  down  and  is  often  filtered  to  share  only  information  that  is  deemed  critical. 
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The  barrier  to  communication  can  influence  project  execution  where  quick  and  accurate  exchange  of  ideas  and 
information  is  critical. 

The  interpretation  of  information  reflects  the  extent  that  context  and  candor  influence  cultural  expressions  of  ideas 
and  understanding  of  information.  In  some  cultures,  an  affirmative  answer  to  a  question  does  not  always  mean 
yes.  The  cultural  influence  can  create  confusion  on  a  project  where  project  stakeholders  represent  more  than  one 
culture. 

Example:  Culture  Affects  Communication  in  Mumbai 

A  project  management  consultant  from  the  United  States  was  asked  to  evaluate  the  effectiveness  of  a  U.S.  project 
management  team  executing  a  project  in  Mumbai,  India.  The  project  team  reported  that  the  project  was  on  sched¬ 
ule  and  within  budget.  After  a  project  review  meeting  where  each  of  the  engineering  leads  reported  that  the  design 
of  the  project  was  on  schedule,  the  consultant  began  informal  discussions  with  individual  engineers  and  began  to 
discover  that  several  critical  aspects  of  the  project  were  behind  schedule.  Without  a  mitigating  strategy,  the  project 
would  miss  a  critical  window  in  the  weather  between  monsoon  seasons.  The  information  on  the  project  flowed 
through  a  cultural  expectation  to  provide  positive  information.  The  project  was  eventually  canceled  by  the  U.S. 
corporation  when  the  market  and  political  risks  increased. 

Not  all  cultural  differences  are  related  to  international  projects.  Corporate  cultures  and  even  regional  differences 
can  create  cultural  confusion  on  a  project. 

Example:  Cultural  Differences  between  American  Regions 

On  a  major  project  in  South  America  that  included  project  team  leaders  from  seven  different  countries,  the  greatest 
cultural  difference  that  affected  the  project  communication  was  between  two  project  leaders  from  the  United 
States.  Two  team  members,  one  from  New  Orleans  and  one  from  Brooklyn,  had  more  difficulty  communicating 
than  team  members  from  Lebanon  and  Australia. 


Managing  Stakeholders 

Often  there  is  more  than  one  major  stakeholder  in  the  project.  An  increase  in  the  number  of  stakeholders  adds 
stress  to  the  project  and  influences  the  project’s  complexity  level.  The  business  or  emotional  investment  of 
the  stakeholder  in  the  project  and  the  ability  of  the  stakeholder  to  influence  the  project  outcomes  or  execution 
approach  will  also  influence  the  stakeholder  complexity  of  the  project.  In  addition  to  the  number  of  stakeholders 
and  their  level  of  investment,  the  degree  to  which  the  project  stakeholders  agree  or  disagree  influences  the  pro¬ 
ject’s  complexity. 

A  small  commercial  construction  project  will  typically  have  several  stakeholders.  All  the  building  permitting 
agencies,  environmental  agencies,  and  labor  and  safety  agencies  have  an  interest  in  the  project  and  can  influence 
the  execution  plan  of  the  project.  The  neighbors  will  have  an  interest  in  the  architectural  appeal,  the  noise,  and  the 
purpose  of  the  building. 
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Example:  Tire  Plant  in  India 

A  U.S.  chemical  company  chartered  a  project  team  to  design  and  build  a  plant  to  produce  the  raw  materials  for 
building  truck  tires  designed  for  unpaved  roads.  The  plant  was  to  be  built  in  India  a  few  years  after  an  accident 
that  killed  several  Indians  and  involved  a  different  U.S.  chemical  company.  When  the  company  announced  the 
new  project  and  began  to  break  ground,  the  community  backlash  was  so  strong  that  the  project  was  shut  down.  A 
highly  involved  stakeholder  can  significantly  influence  your  project. 

Example:  Wind  Turbine  on  a  College  Campus 

A  small  college  in  South  Carolina  won  a  competitive  grant  to  erect  and  operate  a  wind  turbine  on  campus.  The 
engineering  department  submitted  the  grant  as  a  demonstration  project  for  engineering  students  to  expose  students 
to  wind  technology.  The  campus  facilities  department  found  only  one  location  for  the  wind  turbine  that  would  not 
disrupt  the  flow  of  traffic  on  campus.  The  engineering  department  found  that  location  unacceptable  for  students 
who  had  to  maintain  the  wind  turbine.  The  county  construction  permitting  department  had  no  policies  for  per¬ 
mitting  a  wind  turbine  and  would  not  provide  a  building  permit.  The  college  had  to  go  to  the  county  council  and 
get  an  exception  to  county  rules.  The  marketing  department  wanted  the  wind  turbine  placed  in  a  highly  visible 
location  to  promote  the  innovative  approach  of  the  college. 

Each  of  the  college’s  stakeholders  had  a  legitimate  interest  in  the  location  of  the  wind  turbine.  The  number  of 
stakeholders  on  the  project,  multiplied  by  their  passion  for  the  subject  and  the  lack  of  agreement  on  the  location, 
increased  the  complexity  of  the  project.  Significant  time  and  resources  of  a  project  will  be  dedicated  to  identify¬ 
ing,  understanding,  and  managing  client  expectations. 

Example:  Stakeholders  and  a  Bridge  Project 

The  Department  of  Highways  chartered  a  project  to  upgrade  a  number  of  bridges  that  crossed  the  interstate  in  one 
of  the  larger  cities  in  South  Carolina.  The  closing  of  these  bridges  severely  impacted  traffic  congestion,  including 
a  large  shopping  mall.  The  contract  included  provisions  for  minimizing  the  impact  on  the  traffic  and  communities 
near  the  construction  areas.  This  provision  allowed  businesses  or  interested  parties  to  review  the  project  schedule 
and  make  suggestions  that  would  lessen  the  impact  of  the  construction.  The  project  leadership  invested  significant 
time  and  resources  in  developing  alignment  among  the  various  political  stakeholders  on  the  project  approach  and 
schedule. 

Relationship  Building  Tips 

Take  the  time  to  identify  all  stakeholders  before  starting  a  new  project.  Include  those  who  are  impacted  by  the 
project,  as  well  as  groups  with  the  ability  to  impact  the  project.  Then,  begin  the  process  of  building  strong  rela¬ 
tionships  with  each  one  using  the  following  method. 

•  Analyze  stakeholders:  Conduct  a  stakeholder  analysis,  or  an  assessment  of  a  project’s  key  participants,  and 
how  the  project  will  affect  their  problems  and  needs.  Identify  their  individual  characteristics  and  interests. 
Find  out  what  motivates  them,  as  well  as  what  provokes  them.  Define  roles  and  level  of  participation,  and 
determine  if  there  are  conflicts  of  interest  among  groups  of  stakeholders. 

•  Assess  influence:  Measure  the  degree  to  which  stakeholders  can  influence  the  project.  The  more  influential 
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a  stakeholder  is,  the  more  a  project  manager  will  need  their  support.  Think  about  the  question,  “What’s  in  it 
for  them?”  when  considering  stakeholders.  Knowing  what  each  stakeholder  needs  or  wants  from  the  project 
will  enable  the  project  manager  to  gauge  his  or  her  level  of  support.  And  remember  to  balance  support 
against  influence.  Is  it  more  important  to  have  strong  support  from  a  stakeholder  with  little  influence,  or 
lukewarm  support  from  one  with  a  high  level  of  influence? 

•  Understand  their  expectations:  Nail  down  stakeholders’  specific  expectations.  Ask  for  clarification  when 
needed  to  be  sure  they  are  completely  understood. 

•  Define  “success”:  Every  stakeholder  may  have  a  different  idea  of  what  project  success  looks  like.  Discov¬ 
ering  this  at  the  end  of  the  project  is  a  formula  for  failure.  Gather  definitions  up  front  and  include  them  in 
the  objectives  to  help  ensure  that  all  stakeholders  will  be  supportive  of  the  final  outcomes. 

•  Keep  stakeholders  involved:  Don’t  just  report  to  stakeholders.  Ask  for  their  input.  Get  to  know  them  better 
by  scheduling  time  for  coffee,  lunch,  or  quick  meetings.  Measure  each  stakeholder’s  capacity  to  participate 
and  honor  time  constraints. 

•  Keep  stakeholders  informed:  Send  regular  status  updates.  Daily  may  be  too  much;  monthly  is  not  enough. 
One  update  per  week  is  usually  about  right.  Hold  project  meetings  as  required,  but  don’t  let  too  much  time 
pass  between  meetings.  Be  sure  to  answer  stakeholders’  questions  and  emails  promptly.  Regular  communi¬ 
cation  is  always  appreciated  -  and  may  even  soften  the  blow  when  you  have  bad  news  to  share. 

These  are  the  basics  of  building  strong  stakeholder  relationships.  But  as  in  any  relationship,  there  are  subtleties 
that  every  successful  project  manager  understands  -  such  as  learning  the  differences  between  and  relating  well  to 
different  types  stakeholders. 

How  to  Relate  to  Different  Types  of  Stakeholders 

By  conducting  a  stakeholder  analysis,  project  managers  can  gather  enough  information  on  which  to  build  strong 
relationships  -  regardless  of  the  differences  between  them.  For  example,  the  needs  and  wants  of  a  director  of  mar¬ 
keting  will  be  different  from  those  of  a  chief  information  officer.  Therefore,  the  project  manager’s  engagement 
with  each  will  need  to  be  different  as  well. 

Stakeholders  with  financial  concerns  will  need  to  know  the  potential  return  of  the  project’s  outcomes.  Others  will 
support  projects  if  there  is  sound  evidence  of  their  value  to  improving  operations,  boosting  market  share,  increas¬ 
ing  production,  or  meeting  other  company  objectives. 

Keep  each  stakeholder’s  expectations  and  needs  in  mind  throughout  each  conversation,  report  or  email,  no  matter 
how  casual  or  formal  the  communication  may  be.  Remember  that  the  company’s  interests  are  more  important  than 
any  individual’s  -  yours  or  a  stakeholder’s.  When  forced  to  choose  between  them,  put  the  company’s  needs  first. 

No  matter  what  their  needs  or  wants,  all  stakeholders  will  respect  the  project  manager  who: 

•  Is  always  honest,  even  when  telling  them  something  they  don’t  want  to  hear 

•  Takes  ownership  of  the  project 

•  Is  predictable  and  reliable 

•  Stands  by  his  or  her  decisions 
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•  Takes  accountability  for  mistakes 

Supportive  Stakeholders  are  Essential  to  Project  Success 

Achieving  a  project’s  objectives  takes  a  focused,  well-organized  project  manager  who  can  engage  with  a  com¬ 
mitted  team  and  gain  the  support  of  all  stakeholders.  Building  strong,  trusting  relationships  with  interested  parties 
from  the  start  can  make  the  difference  between  project  success  and  failure. 


Tools  to  Help  Stakeholder  Management 

There  are  many  project  decelerators,  among  them  lack  of  stakeholder  support.  Whether  the  stakeholders  support 
your  project  or  not,  if  they  are  important  to  your  project,  you  must  secure  their  support.  How  do  you  do  that? 

First,  you  must  identify  who  your  stakeholders  are.  Just  because  they  are  important  in  the  organization  does  not 
necessarily  mean  they  are  important  to  your  project.  Just  because  they  think  they  are  important  does  not  mean 
they  are.  Just  because  they  don’t  think  they  need  to  be  involved  does  not  mean  they  do  not  have  to  be.  The  typical 
suspects:  your  manager,  your  manager’s  manager,  your  client,  your  client’s  manager,  any  SME  (subject  matter 
expert)  whose  involvement  you  need,  and  the  board  reviewing  and  approving  your  project.  Note  that  in  some  sit¬ 
uations  there  are  people  who  think  they  are  stakeholders.  From  your  perspective  they  may  not  be,  but  be  careful 
how  you  handle  them.  They  could  be  influential  with  those  who  have  the  power  to  impact  your  project.  Do  not 
dismiss  them  out  of  hand. 

Second,  you  need  to  determine  what  power  they  have  and  what  their  intentions  toward  your  project  are.  Do  they 
have  the  power  to  have  an  impact  on  your  project?  Do  they  support  or  oppose  you?  What  strategies  do  you  follow 
with  them? 

Third,  what’s  the  relationship  among  stakeholders?  Can  you  improve  your  project’s  chances  by  working  with 
those  who  support  you  to  improve  the  views  of  those  who  oppose  you?  Figure  5.2  summarizes  the  options  based 
on  an  assessment  of  your  stakeholders’  potential  for  cooperation  and  potential  for  threat. 


Figure  5.2  Stakeholder  Analysis 

Source:  http://svprojectmanagement.com/ 

project-decelerators-%E2%80%93-lack-of-stakeholder-support 


Now  that  you  have  this  information,  you  can  complete  a  stakeholder  analysis  template  (Table  5.1)  that  will  help 
you  define  your  strategies  to  improve  their  support: 
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Stakeholder 
Names  and 
Roles 


How  important? 
(Low  -  Med  - 
High) 


Current  level  of  sup¬ 
port?  (Low  -  Med  - 
High) 


What  do  you  want 
from  stakeholders? 


What  is  impor¬ 
tant  to  stakehold¬ 
ers? 


How  could  stakehold¬ 
ers  block  your 
efforts? 


What  is  your  strategy  for 
enhancing  stakeholder  sup¬ 
port? 


Table  5.1  Stakeholder  Analysis  Template 

Source:  http://svprojectmanagement.com/project-decelerators-%E2%80%93-lack-of-stakeholder-support 


Finally,  a  key  piece  of  your  stakeholder  management  efforts  is  constant  communication  to  your  stakeholders. 
Using  the  information  developed  above,  you  should  develop  a  communications  plan  that  secures  your  stakehold¬ 
ers’  support.  The  template  in  Table  5.2  can  be  used. 


Table  5.2  Stakeholder  Analysis  Template 
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6.  Culture  and  Project  Management 


ADRIENNE  WATT 


What  Is  Organizational  Culture? 

When  working  with  internal  and  external  customers  on  a  project,  it  is  essential  to  pay  close  attention  to  relation¬ 
ships,  context,  history,  and  the  corporate  culture.  Corporate  culture  refers  to  the  beliefs,  attitudes,  and  values  that 
the  organization’s  members  share  and  the  behaviors  consistent  with  them  (which  they  give  rise  to).  Corporate  cul¬ 
ture  sets  one  organization  apart  from  another,  and  dictates  how  members  of  the  organization  will  see  you,  interact 
with  you,  and  sometimes  judge  you.  Often,  projects  too  have  a  specific  culture,  work  norms,  and  social  conven¬ 
tions. 

Some  aspects  of  corporate  culture  are  easily  observed;  others  are  more  difficult  to  discern.  You  can  easily  observe 
the  office  environment  and  how  people  dress  and  speak.  In  one  company,  individuals  work  separately  in  closed 
offices;  in  another,  teams  may  work  in  a  shared  environment.  The  more  subtle  components  of  corporate  culture, 
such  as  the  values  and  overarching  business  philosophy,  may  not  be  readily  apparent,  but  they  are  reflected  in 
member  behaviors,  symbols,  and  conventions  used. 


Project  Manager's  Checklist 

Once  the  corporate  culture  has  been  identified,  members  should  try  to  adapt  to  the  frequency,  formality,  and  type 
of  communication  customary  in  that  culture.  This  adaptation  will  strongly  affect  project  members’  productivity 
and  satisfaction  internally,  as  well  as  with  the  client  organization. 

•  Which  stakeholders  will  make  the  decision  in  this  organization  on  this  issue?  Will  your  project  decisions 
and  documentation  have  to  go  up  through  several  layers  to  get  approval?  If  so,  what  are  the  criteria  and  val¬ 
ues  that  may  affect  acceptance  there?  For  example,  is  being  on  schedule  the  most  important  consideration? 
Cost?  Quality? 

•  What  type  of  communication  among  and  between  stakeholders  is  preferred?  Do  they  want  lengthy  docu¬ 
ments?  Is  “short  and  sweet”  the  typical  standard? 

•  What  medium  of  communication  is  preferred?  What  kind  of  medium  is  usually  chosen  for  this  type  of  situa- 
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tion?  Check  the  files  to  see  what  others  have  done.  Ask  others  in  the  organization. 

•  What  vocabulary  and  format  are  used?  What  colors  and  designs  are  used  (e.g.,  at  Hewlett-Packard,  all  rec¬ 
tangles  have  curved  corners)? 


Project  Team  Challenges 

Today’s  globally  distributed  organizations  (and  projects)  consist  of  people  who  have  differing  “worldviews.” 
Worldview  is  a  looking  glass  through  which  people  see  the  world  as  Bob  Shebib  describes:  “[It  is]  a  belief  system 
about  the  nature  of  the  universe,  its  perceived  effect  on  human  behavior,  and  one’s  place  in  the  universe.  World¬ 
view  is  a  fundamental  core  set  of  assumptions  explaining  cultural  forces,  the  nature  of  humankind,  the  nature  of 
good  and  evil,  luck,  fate,  spirits,  the  power  of  significant  others,  the  role  of  time,  and  the  nature  of  our  physical 
and  natural  resources”  (Shebib,  2003,  p.  296). 

If,  for  example,  a  Canadian  manager  is  sent  to  India  to  manage  an  R&D  team  or  a  joint  venture,  they  are  likely 
to  have  to  “[cope]  with  eco-shock  or  the  physiological,  psychological,  and  social  reaction  to  a  new  assignment 
ecology.”  Hanging  a  shingle  in  a  fluid  and  culturally  diverse  organization,  project  team,  and  work  culture,  a  pro¬ 
ject  manager  may  find  new  working  relationships  and  hidden  challenges  have  significant  implications  for  perfor¬ 
mance  and  knowledge  exchange  -  for  the  manager  and  colleagues  at  home  and  in  the  host  country. 

In  most  situations,  there  is  simply  no  substitute  for  having  a  well-placed  person  from  the  host  culture  to  guide 
the  new  person  through  the  cultural  nuances  of  getting  things  done.  In  fact,  if  this  “intervention”  isn’t  present, 
it  is  likely  to  affect  the  person’s  motivation  or  desire  to  continue  trying  to  break  through  the  cultural  (and  other) 
barriers.  Indeed,  optimal  effectiveness  in  such  situations  requires  learning  of  cultures  in  developing  countries  or 
international  micro-cultures  and  sharing  perceptions  among  the  culturally  diverse  task  participants  on  how  to  get 
things  done.  Project  leaders  require  sensitivity  and  awareness  of  multicultural  preferences.  The  following  broad 
areas  should  be  considered: 

•  Individual  identity  and  role  within  the  project  versus  family  of  origin  and  community 

•  Verbal  and  emotional  expressiveness 

•  Relationship  expectations 

•  Style  of  communication 

•  Language 

•  Personal  priorities,  values,  and  beliefs 

•  Time  orientation 

There  are  many  interpersonal  dynamics  and  intra-project  challenges  faced  by  a  globally  distributed  team.  Individ¬ 
ual  members  and  the  team  itself  requires  important  social  supports  to  mitigate  uncertainty,  conflict,  motivational 
challenges,  culture  shock,  and  the  more-encompassing  eco-shock  that  comes  from  facing  head-on  the  unfamiliar 
and  diverse  situations  consistent  with  a  different  cultural  and  geographically  distributed  context. 


Diverse  and  globally  distributed  project  teams  (i.e.,  different  ethnic  cultures,  genders,  ages,  and  functional  capa¬ 
bilities),  often  working  on  complex  projects  spanning  multiple  time  zones,  geography,  and  history,  and  operating 
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with  tight  deadlines  in  cost-conscious  organizations,  need  to  make  time  and  resources  available  to  physically  meet 
each  other,  and  connect  (at  the  very  least)  at  a  formal  “kick-off”  meeting.  Especially  when  working  with  team 
members  from  high-context  cultures,  it  is  essential  to  meet  face-to-face,  discover  member’s  individual  identities 
and  cultural  preferences,  share  professional  knowledge  and  personal  stories,  and  observe  critical  verbal  and  non¬ 
verbal  cues  (that  may  not  easily  be  observed  online,  or  on  the  telephone).  This  is  key  to  establishing  a  safer  climate 
and  building  trust  for  stronger  relationships  among  both  team  members  and  management. 


Dealing  with  Conflict 

The  question  isn’t  whether,  when,  or  with  what  frequency  conflict  will  occur  among  intercultural  team  members 
—  or  what  will  create  the  conflict.  If  a  team  wants  to  overcome  (or  harness)  conflict  for  effectiveness  and  produc¬ 
tivity,  the  question  is  how  to  navigate  and  resolve  the  conflicts.  Conflict  that  springs  from  diversity  can  actually 
assist  the  team  in  completing  complex  problem  solving.  However,  if  not  navigated  successfully,  it  can  create  rela¬ 
tionship  strain  and  derail  achievement  due  to  increased  difficulties  in  communication  and  coordination. 

As  the  global  marketplace  continues  its  rapid  expansion,  researchers  are  increasingly  turning  their  attention  to 
the  issue  of  conflict  management.  Differing  social  and  cultural  values  don’t  necessarily  increase  the  number  of 
conflicts  a  team  will  experience,  but  they  can  have  an  impact  on  how  conflicts  are  managed  and  resolved.  Cul¬ 
tural  awareness  is  needed  for  understanding  and  appreciating  others’  values  and  behavioral  norms.  Without  that, 
foreign  assignments  will  become  an  overwhelming  challenge.  Self-awareness  and  skill  development  can  aid  in 
resolving  the  problematic  conflict  arising  from  cultural  differences  to  help  a  team  maintain  good  relations  and 
remain  productive. 
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7.  Project  Initiation 
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The  project  initiation  phase  is  the  first  phase  within  the  project  management  life  cycle,  as  it  involves  starting  up 
a  new  project.  Within  the  initiation  phase,  the  business  problem  or  opportunity  is  identified,  a  solution  is  defined, 
a  project  is  formed,  and  a  project  team  is  appointed  to  build  and  deliver  the  solution  to  the  customer.  A  business 
case  is  created  to  define  the  problem  or  opportunity  in  detail  and  identify  a  preferred  solution  for  implementation. 
The  business  case  includes: 

•  A  detailed  description  of  the  problem  or  opportunity  with  headings  such  as  Introduction,  Business  Objec¬ 
tives,  Problem/Opportunity  Statement,  Assumptions,  and  Constraints 

•  A  list  of  the  alternative  solutions  available 

•  An  analysis  of  the  business  benefits,  costs,  risks,  and  issues 

•  A  description  of  the  preferred  solution 

•  Main  project  requirements 

•  A  summarized  plan  for  implementation  that  includes  a  schedule  and  financial  analysis 

The  project  sponsor  then  approves  the  business  case,  and  the  required  funding  is  allocated  to  proceed  with  a  feasi¬ 
bility  study.  It  is  up  to  the  project  sponsor  to  determine  if  the  project  is  worth  undertaking  and  whether  the  project 
will  be  profitable  to  the  organization.  The  completion  and  approval  of  the  feasibility  study  triggers  the  beginning 
of  the  planning  phase.  The  feasibility  study  may  also  show  that  the  project  is  not  worth  pursuing  and  the  project 
is  terminated;  thus  the  next  phase  never  begins. 

All  projects  are  created  for  a  reason.  Someone  identifies  a  need  or  an  opportunity  and  devises  a  project  to  address 
that  need.  How  well  the  project  ultimately  addresses  that  need  defines  the  project’s  success  or  failure. 

The  success  of  your  project  depends  on  the  clarity  and  accuracy  of  your  business  case  and  whether  people  believe 
they  can  achieve  it.  Whenever  you  consider  past  experience,  your  business  case  is  more  realistic;  and  whenever 
you  involve  other  people  in  the  business  case’s  development,  you  encourage  their  commitment  to  achieving  it. 

Often  the  pressure  to  get  results  encourages  people  to  go  right  into  identifying  possible  solutions  without  fully 
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understanding  the  need  or  what  the  project  is  trying  to  accomplish.  This  strategy  can  create  a  lot  of  immediate 
activity,  but  it  also  creates  significant  chances  for  waste  and  mistakes  if  the  wrong  need  is  addressed.  One  of 
the  best  ways  to  gain  approval  for  a  project  is  to  clearly  identify  the  project’s  objectives  and  describe  the  need 
or  opportunity  for  which  the  project  will  provide  a  solution.  For  most  of  us,  being  misunderstood  is  a  common 
occurrence,  something  that  happens  on  a  daily  basis.  At  the  restaurant,  the  waiter  brings  us  our  dinner  and  we 
note  that  the  baked  potato  is  filled  with  sour  cream,  even  though  we  expressly  requested  “no  sour  cream.”  Pro¬ 
jects  are  filled  with  misunderstandings  between  customers  and  project  staff.  What  the  customer  ordered  (or  more 
accurately  what  they  think  they  ordered)  is  often  not  what  they  get.  The  cliche  is  “I  know  that’s  what  I  said,  but 
it’s  not  what  I  meant.”  Figure  7.1  demonstrates  the  importance  of  establishing  clear  objectives. 

The  need  for  establishing  clear  project  objectives  cannot  be  overstated.  An  objective  or  goal  lacks  clarity  if,  when 
shown  to  five  people,  it  is  interpreted  in  multiple  ways.  Ideally,  if  an  objective  is  clear,  you  can  show  it  to  five 
people  who,  after  reviewing  it,  hold  a  single  view  about  its  meaning.  The  best  way  to  make  an  objective  clear  is  to 
state  it  in  such  a  way  that  it  can  be  verified.  Building  in  ways  to  measure  achievement  can  do  this.  It  is  important 
to  provide  quantifiable  definitions  to  qualitative  terms. 


Figure  7.1:  Project  Management  by  Andreas  Cappell 

(https://www.flickr.com/photos/cappellmeister/5921913/)  used 
under  CC-BY-NC-SA  (https://creativecommons.org/licenses/ 
by-nc-sa/2.0/) 


For  example,  an  objective  of  the  team  principle  (project  manager)  of  a  Formula  1  racing  team  may  be  that  their 
star  driver,  “finish  the  lap  as  fast  as  possible.”  That  objective  is  filled  with  ambiguity. 

How  fast  is  “fast  as  possible?”  Does  that  mean  the  fastest  lap  time  (the  time  to  complete  one  lap)  or  does  it  mean 
the  fastest  speed  as  the  car  crosses  the  start/finish  line  (that  is  at  the  finish  of  the  lap)? 

By  when  should  the  driver  be  able  to  achieve  the  objective?  It  is  no  use  having  the  fastest  lap  after  the  race  has 
finished,  and  equally  the  fastest  lap  does  not  count  for  qualifying  and  therefore  starting  position,  if  it  is  performed 
during  a  practice  session. 

The  ambiguity  of  this  objective  can  be  seen  from  the  following  example.  Ferrari’s  Michael  Schumacher  achieved 
the  race  lap  record  at  the  Circuit  de  Monaco  of  1  min  14.439  sec  in  2004  (Figure  7.2).  However,  he  achieved  this 
on  lap  23  of  the  race,  but  crashed  on  lap  44  of  a  77-lap  race.  So  while  he  achieved  a  fastest  lap  and  therefore 
met  the  specific  project  goal  of  “finish  the  lap  as  fast  as  possible,”  it  did  not  result  in  winning  the  race,  clearly  a 
different  project  goal.  In  contrast,  the  fastest  qualifying  time  at  the  same  event  was  by  Renault’s  Jarno  Trulli  (1 
min  13.985  sec),  which  gained  him  pole  position  for  the  race,  which  he  went  on  to  win  (Figure  7.2).  In  his  case, 
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he  achieved  the  specific  project  goal  of  “finish  the  lap  as  fast  as  possible,”  but  also  the  larger  goal  of  winning  the 
race. 

The  objective  can  be  strengthened  considerably  if  it  is  stated  as  follows:  “To  be  able  to  finish  the  3.340  km  lap  at 
the  Circuit  de  Monaco  at  the  Monaco  Grand  Prix  in  1  min  14.902  sec  or  less,  during  qualifying  on  May  23,  2009.” 
This  was  the  project  objective  achieved  by  Brawn  GP’s  Jenson  Button  (Figure  7.2). 


Figure  7.2:  Despite  achieving  the 
project  goal  of  the  “finish  the  lap  as 
fast  as  possible,”  Ferrari’s  Michael 
Schumacher  crashed  21  laps  later  and 
did  not  finish  the  race  (top);  Renault’s 
Jarno  Trulli  celebrating  his  win  at  the 
2004  Monaco  Grand  Prix  (middle); 
Jenson  Button  took  his  Brawn  GP  car 
to  pole  position  at  the  Monaco  Grand 
Prix  with  a  lap  time  of  1  min  14.902 
sec.  He  also  went  on  to  win  the  race, 
even  though  he  did  not  achieve  that 
lap  time  during  the  race  (bottom). 
Monaco  2004  by  Cord  Rodefeld 
(https://www.flickr.com/photos/ 
rodefeld/386917280/)  used  under 
CC-BY  license 
(https://creativecommons.org/ 
licenses/by/2.0/)  (top);  Jarno  Trulli  by 
ph-stop  (https://www.fhckr.com/ 
photos/ph-stop/4698634584/)  used 
under  CC-BY- SA  license 
(https://creativecommons.org/ 
licenses/by-sa/2.0/)  (middle);  Jenson 
Button  by  Evoflash 
(https://www.flickr.com/photos/ 
evoflash/7614681230/)  used  under 
CC-BY  license 
(https://creativecommons.org/ 
licenses/by/2.0/)  (bottom) 


There  is  still  some  ambiguity  in  this  objective;  for  example,  it  assumes  the  star  driver  will  be  driving  the  team’s 
race  car  and  not  a  rental  car  from  Hertz.  However,  it  clarifies  the  team  principal’s  intent  quite  nicely.  It  should  be 
noted  that  a  clear  goal  is  not  enough.  It  must  also  be  achievable.  The  team  principal’s  goal  becomes  unachievable, 
for  example,  if  he  changes  it  to  require  his  star  driver  to  finish  the  3.340  km  lap  in  30  sec  or  less. 
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To  ensure  the  project’s  objectives  are  achievable  and  realistic,  they  must  be  determined  jointly  by  managers  and 
those  who  perform  the  work.  Realism  is  introduced  because  the  people  who  will  do  the  work  have  a  good  sense 
of  what  it  takes  to  accomplish  a  particular  task.  In  addition,  this  process  assures  some  level  of  commitment  on  all 
sides:  management  expresses  its  commitment  to  support  the  work  effort  and  workers  demonstrate  their  willing¬ 
ness  to  do  the  work. 

Imagine  an  office  manager  has  contracted  a  painter  to  paint  his  office.  His  goal  or  objective  is  to  have  the  office 
painted  a  pleasing  blue  color.  Consider  the  conversation  that  occurs  in  Figure  7.3  after  the  job  was  finished. 


Csk| 


Figure  7.3:  The  consequence  of  not  making  your 
objective  clear. 

Illustration  from  Barron  &  Barron  Project 
Management  for  Scientists  and  Engineers, 

http://cnx.Org/content/collll20/l.4/ 


This  conversation  captures  in  a  nutshell  the  essence  of  a  major  source  of  misunderstandings  on  projects:  the 
importance  of  setting  clear  objectives.  The  office  manager’s  description  of  how  he  wanted  the  room  painted  meant 
one  thing  to  him  and  another  to  the  painter.  As  a  consequence,  the  room  was  not  painted  to  the  office  manager’s 
satisfaction.  Had  his  objective  been  more  clearly  defined,  he  probably  would  have  had  what  he  wanted. 


Comparing  Options  Using  a  Weighted  Decision  Matrix 

Sometimes  we  have  multiple  options  to  choose  from  when  determining  requirements  and  deciding  which  project 
to  work  on.  To  select  the  best  option,  we  can  use  tools  such  as  a  weighted  decision  matrix. 

A  basic  decision  matrix  consists  of  establishing  a  set  of  criteria  for  options  that  are  scored  and  summed  to  gain  a 
total  score  that  can  then  be  ranked.  Importantly,  it  is  not  weighted  to  allow  a  quick  selection  process. 

A  weighted  decision  matrix  operates  in  the  same  way  as  the  basic  decision  matrix  but  introduces  the  concept  of 
weighting  the  criteria  in  order  of  importance.  The  resultant  scores  better  reflect  the  importance  to  the  decision 
maker  of  the  criteria  involved.  The  more  important  a  criterion,  the  higher  the  weighting  it  should  be  given.  Each 
of  the  potential  options  is  scored  and  then  multiplied  by  the  weighting  given  to  each  of  the  criteria  to  produce  a 
result. 

The  advantage  of  the  weighted  decision  matrix  is  that  subjective  opinions  about  one  alternative  versus  another  can 
be  made  more  objective.  Another  advantage  of  this  method  is  that  sensitivity  studies  can  be  performed.  An  exam¬ 
ple  of  this  might  be  to  see  how  much  your  opinion  would  have  to  change  in  order  for  a  lower-ranked  alternative 
to  outrank  a  competing  alternative. 
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A  weighted  decision  matrix  therefore  allows  decision  makers  to  structure  and  solve  their  problem  by: 

1.  Specifying  and  prioritizing  their  needs  with  a  list  a  criteria;  then 

2.  Evaluating,  rating,  and  comparing  the  different  solutions;  and 

3.  Selecting  the  best  matching  solution. 

A  weighted  decision  matrix  is  a  decision  tool  used  by  decision  makers. 

A  decision  matrix  is  basically  an  array  presenting  on  one  axis  a  list  of  alternatives,  also  called  options  or  solu¬ 
tions,  that  are  evaluated  regarding,  on  the  other  axis,  a  list  of  criteria,  which  are  weighted  depending  on  their 
respective  importance  in  the  final  decision  to  be  taken. 

Weighted  Decision  Matrix  Sample 

The  example  in  Figure  7.4  shows  a  weighted  decision  matrix  that  compared  three  options  for  a  web  development 
project  (SJS  Enterprises).  This  method  is  especially  useful  when  choosing  purchase  alternatives  and  comparing 
them  against  specific  desirable  system  requirements. 


Figure  7.4:  Weighted  Decision  Matrix  for  Game  Delivery 
Project  Source:  A.  Watt 


Financial  Considerations 

In  many  new  project  endeavors,  we  need  to  find  out  if  our  project  is  financially  feasible.  We  do  that  by  using  net 
present  value  (NPV),  rate  of  return  (ROI),  and  payback  analysis. 

NPV 

A  dollar  earned  today  is  worth  more  than  a  dollar  earned  one  or  more  years  from  now.  The  NPV  of  a  time  series 
of  cash  flows,  both  incoming  and  outgoing,  is  defined  as  the  sum  of  the  present  values  (PVs)  of  the  individual 
cash  flows  of  the  same  entity. 

In  the  case  when  all  future  cash  flows  are  incoming  and  the  only  outflow  of  cash  is  the  purchase  price,  the  NPV 
is  simply  the  PV  of  future  cash  flows  minus  the  purchase  price  (which  is  its  own  PV).  NPV  is  a  standard  method 
for  using  the  time  value  of  money  to  appraise  long-term  projects.  Used  for  capital  budgeting  and  widely  used 
throughout  economics,  finance,  and  accounting,  it  measures  the  excess  or  shortfall  of  cash  flows,  in  present  value 
terms,  once  financing  charges  are  met. 
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NPV  can  be  described  as  the  “difference  amount”  between  the  sums  of  discounted  cash  inflows  and  cash  outflows. 


It  compares  the  present  value  of  money  today  to  the  present  value  of  money  in  the  future,  taking  inflation  and 
returns  into  account. 

The  NPV  of  a  sequence  of  cash  flows  takes  as  input  the  cash  flows  and  a  discount  rate  or  discount  curve  and 
outputs  a  price. 

Each  cash  inflow/outflow  is  discounted  back  to  its  present  value  (PV).  Then  they  are  summed.  Therefore  NPV  is 
the  sum  of  all  terms. 


where 

t  is  the  time  of  the  cash  flow 

z  is  the  discount  rate  (the  rate  of  return  that  could  be  earned  on  an  investment  in  the  financial  markets  with  similar 
risk;  the  opportunity  cost  of  capital) 

Rt  is  the  net  cash  flow  (i.e.,  cash  inflow  -  cash  outflow,  at  time  t). 

NPV  is  an  indicator  of  how  much  value  an  investment  or  project  adds  to  the  firm.  With  a  particular  project,  if 
NPV  is  a  positive  value,  the  project  is  in  the  status  of  positive  cash  inflow  in  the  time  t.  If  NPV  is  a  negative  value, 
the  project  is  in  the  status  of  discounted  cash  outflow  in  the  time  t.  Sometimes  risky  projects  with  a  positive  NPV 
could  be  accepted.  This  does  not  necessarily  mean  that  they  should  be  undertaken  since  NPV  at  the  cost  of  capital 
may  not  account  for  opportunity  cost  (i.e.,  comparison  with  other  available  investments).  In  financial  theory,  if 
there  is  a  choice  between  two  mutually  exclusive  alternatives,  the  one  yielding  the  higher  NPV  should  be  selected. 
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If... 

It  means... 

Then... 

NPV  >  0 

The  investment  would  add 
value  to  the  firm. 

The  project  may  be  accepted. 

NPV  <  0 

The  investment  would  sub¬ 
tract  value  from  the  firm. 

The  project  should  be  rejected. 

NPV  =  0 

The  investment  would  nei¬ 
ther  gain  nor  lose  value  for 
the  firm. 

We  should  be  indifferent  in  the  decision  whether  to  accept  or  reject 
the  project.  This  project  adds  no  monetary  value.  Decision  should  be 
based  on  other  criteria  (e.g.,  strategic  positioning  or  other  factors  not 
explicitly  included  in  the  calculation). 

Table  7.1:  Net  Present  Value 

Source:  http://en.wikipedia.org/wiki/Net_present_value 


Present  Value  Table 


Periods 

6% 

8% 

10% 

12% 

14% 

1 

0.943 

0.926 

0.909 

0.893 

0.877 

2 

0.890 

0.857 

0.826 

0.797 

0.769 

3 

0.840 

0.794 

0.751 

0.712 

0.675 

4 

0.792 

0.735 

0.683 

0.636 

0.592 

5 

0.747 

0.681 

0.621 

0.567 

0.519 

6 

0.705 

0.630 

0.564 

0.507 

0.456 

7 

0.665 

0.583 

0.513 

0.452 

0.400 

8 

0.627 

0.540 

0.467 

0.404 

0.351 

9 

0.592 

0.500 

0.424 

0.361 

0.308 

10 

0.558 

0.463 

0.386 

0.322 

0.270 

Table  7.2:  Take  note  of  the  decreasing  value  of  money  as  the  period  increases  from  1  to  10  years. 
Source:  A.  Watt 


NPV  Example 

The  following  example  is  calculating  the  NPV  of  a  project  at  a  discount  rate  of  12%.  The  project  takes  five  years 
to  complete  with  given  benefits  and  costs  for  each  year.  In  Year  0,  there  is  no  benefit  to  the  organization,  just  an 
initial  cost  of  $75,000  with  no  discount  rate.  In  Year  1,  the  discount  rate  is  89%.  This  means  that  at  12%  assumed 
interest,  the  time  value  of  money  says  that  the  $1  today  is  worth  $0.89  in  one  year,  $0.80  in  two  years,  etc.  By 
calculating  the  NPV  for  the  benefits  and  the  costs,  you  subtract  the  NPV  of  all  costs  from  the  NPV  of  all  benefits. 
The  final  result  is  a  positive  value  of  $105,175. 
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:: 


Table  7.3:  Table  of  NPV  of  costs  and  benefits. 
Source:  A.  Watt 


ROI 

Return  on  investment  (ROI)  is  a  performance  measure  used  to  evaluate  the  efficiency  of  an  investment  or  to 
compare  the  efficiency  of  a  number  of  different  investments.  It  is  one  way  of  considering  profits  in  relation  to 
capital  invested. 

This  is  calculated  by  subtracting  the  project’s  costs  from  the  benefits  and  then  dividing  by  the  costs.  For  example, 
if  you  invest  $100  and  your  investment  is  worth  $110  next  year,  the  ROI  is  (110-100)/100  =  0.1  or  a  10%  return. 

In  our  example:  (306,425-201,175)/  201,175  =  .52  =  52%  return.  That’s  considered  a  nice  return  on  investment. 

Payback  Period 

Payback  analysis  is  important  in  determining  the  amount  of  time  it  will  take  for  a  project  to  recoup  its  investments. 
This  is  the  point  at  which  the  benefits  start  to  outweigh  the  costs.  The  best  way  to  see  that  is  by  charting  the 
cumulative  benefits  and  costs.  As  you  can  see  in  the  example  in  Figure  7.5,  the  cumulative  benefits  outweigh  the 
cumulative  costs  in  the  second  year. 


Figure  7.5:  Payback  Analysis  Chart. 
Source:  A.  Watt 


Project  Charter 

A  project  charter,  project  definition,  or  project  statement  is  a  statement  of  the  scope,  objectives,  and  participants  in 
a  project.  It  provides  a  preliminary  delineation  of  roles  and  responsibilities,  outlines  the  project  objectives,  iden¬ 
tifies  the  main  stakeholders,  and  defines  the  authority  of  the  project  manager.  It  serves  as  a  reference  of  authority 
for  the  future  of  the  project. 


Purpose  of  the  Project  Charter 

The  purpose  of  a  project  charter  is  to: 
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•  Provide  an  understanding  of  the  project,  the  reason  it  is  being  conducted,  and  its  justification 

•  Establish  early  on  in  the  project  the  general  scope 

•  Establish  the  project  manager  and  his  or  her  authority  level.  A  note  of  who  will  review  and  approve  the  pro¬ 
ject  charter  must  be  included. 

Simple  example  of  project  charter 

Identification  Section 

List  the  project  name,  the  date  of  the  current  version  of  the  project  charter,  the  sponsor’s  name  and  authority,  and 
the  project  manager’s  name. 

Example: 

Project  Name:  Rice  University  Computer  Store  Creation 
Project  Sponsor:  Jane  Ungam,  Facilities  Manager 
Date:  Jan  12,  2010 
Revision:  1 

Project  Manager:  Fred  Rubens 

Overview  of  the  Project 

Provide  a  simple  but  precise  statement  of  the  project. 

Example:  Rice  University  is  planning  to  create  a  store  to  sell  computer  supplies. 

Objective 

State  the  objectives  of  the  project  clearly  and  ensure  they  contain  a  measure  of  how  to  assess  whether  they  have 
been  achieved.  The  statement  should  be  realistic  and  should  follow  the  SMART  protocol: 

•  Specific  (get  into  the  details) 

•  Measurable  (use  quantitative  language  so  that  you  know  when  you  are  finished) 

•  Acceptable  (to  stakeholders) 

•  Realistic  (given  project  constraints) 

•  Time  based  (deadlines,  not  durations) 

Example:  The  objective  of  this  project  is  to  implement  a  campus  store  that  is  ready  to  sell  computer  supplies 
such  as  memory  sticks,  mouse  pads,  and  cables,  when  class  starts  in  August  2010,  with  enough  inventory  to  last 
through  the  first  two  weeks  of  classes. 


Scope 
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Specify  the  scope  of  the  project  by  identifying  the  domain  or  range  of  requirements. 

Example:  The  scope  of  the  Rice’s  school  supplies  store  project  includes  the  activities  listed  below: 

1.  Determine  what  supplies  will  be  sold  in  the  store. 

2.  Establish  competitive  prices  for  the  computer  supplies. 

3.  Source  and  secure  supply  vendors. 

4.  Establish  marketing,  procurement,  operations,  and  any  other  necessary  departments,  schools,  centers,  and 
institutes. 

It  is  equally  important  to  include  in  the  scope  what  is  not  included  in  the  project. 

Example:  The  scope  of  the  project  does  not  include: 

•  Development  of  any  other  school  store  departments 

•  Store  design  or  construction 

Major  Milestones 

List  all  major  milestones  needed  to  ensure  project  completion  successfully. 

Example: 

•  All  vendors  selected 

•  Contracts  or  orders  completed  with  all  vendors 

•  Supplies  delivered  to  the  store 

•  Pricing  determined 

Major  Deliverables 

List  and  describe  the  major  deliverables  that  will  result  from  the  project. 

Example: 

•  Supplies  procured 

•  Operations,  procurement,  marketing,  and  other  teams  established 

•  Store  supplies  stocked  and  displayed 

•  Store  staffing  completed,  including  work  schedules 

•  Store  operations  policies,  including  hours  of  operation,  established 

Assumptions 

Outline  the  assumptions  made  in  creating  the  project.  An  assumption  is  a  fact  you  are  unsure  of  but  can  either 
confirm  at  a  later  time  or  are  simply  stating  so  that  the  project  can  proceed  as  if  the  statement  were  true. 
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Example: 

•  Only  computer  supplies  will  be  sold  in  the  store. 

•  Customers  will  be  the  Rice  University  student  body  and  faculty. 

•  Rice  University  students  will  manage  the  project  and  be  responsible  for  ongoing  operations. 

•  A  store  sponsor  from  the  university  faculty  or  staff  will  be  assigned  to  mentor  students  and  provide  over¬ 
sight. 

•  Store  hours  of  operation  will  be  approved  by  the  Rice  University  students  or  store  sponsor. 

•  Supplier  deliveries  will  be  arranged  or  the  store  sponsor  will  pick  them  up  with  students. 

•  Students  will  be  empowered  to  contact  vendors  for  order  placement  and  inquiries  via  telephone. 

Constraints 

Define  any  and  all  constraints  on  the  project  or  those  working  on  the  project.  This  is  an  important  part  of  the  pro¬ 
ject  charter.  A  constraint  is  anything  that  limits  the  range  of  solutions  or  approaches. 

Example: 

•  Student  availability  to  meet  for  project  planning  is  limited  to  school  hours. 

•  Software  is  not  available  for  project  planning  and  control. 

Business  Need  or  Opportunity  (Benefits) 

Provide  a  concise  statement  of  the  business  need  or  opportunity  that  led  to  the  creation  of  the  project.  Why  was  it 
created?  What  are  the  benefits?  How  does  the  project  contribute  to  organizational  objectives? 

Example:  The  goal  of  this  project  is  to  provide  income  for  the  Rice  Student  Center  while  supplying  necessary 
items  to  students  and  faculty  at  competitive  prices.  The  school  store  will  be  a  convenience  to  students  since  nec¬ 
essary  supplies  will  be  available  on  campus.  This  will  help  students  learn  to  manage  their  personal  supplies. 

Preliminary  Cost  for  the  Project 

Provide  a  statement  indicating  how  the  cost  of  the  project  will  be  defined  and  controlled. 

Example:  The  procurement  team  will  assemble  a  proposal  based  on  expected  costs  for  review  by  the  Dean  of 
Undergraduate  Studies. 

Project  Risks 

A  risk  is  anything  uncertain  that  may  occur  that  will  reduce  or  decrease  the  chances  of  project  success. 

Example: 

1.  There  is  a  state  election  coming  and  the  new  government  may  change  the  taxation  rules  for  private  university 
retail  outlets. 
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2.  The  cloud  is  changing  student  demand  for  media  such  as  flash  drives  in  somewhat  unpredictable  ways.  If  this 
happens  faster  than  we  forecast,  we  may  be  building  a  store  that  students  don’t  need. 

3.  Deliveries  of  store  shelves,  etc.  will  be  delayed  if  a  major  hurricane  occurs. 

Project  Charter  Acceptance 

Provide  the  names,  titles,  and  signature  lines  of  the  individuals  who  will  sign  off  on  the  project  charter. 

Project  Stakeholders 

Provide  the  key  stakeholders  and  team  members  by  function,  name,  and  role. 


Function 

Name 

Role 

Project  Manager 

Monica  Styles 

Leads  the  project 

Sponsor 

Adrienne  Watt 

Project  sponsor 

etc. 

Attribution 

This  chapter  of  Project  Management  is  a  derivative  copy  of  Project  Management  by  Merrie  Barron  and  Andrew 
Barron  licensed  under  and  Creative  Commons  Attribution  3.0  Unported  and  Decision  Matrix  Method  and  Project 
Charter  by  Wikipedia  the  Free  Encyclopedia  licensed  under  Creative  Commons  Share  Alike  Attribution  3.0 
Unported. 


8.  Overview  of  Project  Planning 


ADRIENNE  WATT 


After  the  project  has  been  defined  and  the  project  team  has  been  appointed,  you  are  ready  to  enter  the  second 
phase  in  the  project  management  life  cycle:  the  detailed  project  planning  phase. 

Project  planning  is  at  the  heart  of  the  project  life  cycle,  and  tells  everyone  involved  where  you’re  going  and  how 
you’re  going  to  get  there.  The  planning  phase  is  when  the  project  plans  are  documented,  the  project  deliverables 
and  requirements  are  defined,  and  the  project  schedule  is  created.  It  involves  creating  a  set  of  plans  to  help  guide 
your  team  through  the  implementation  and  closure  phases  of  the  project.  The  plans  created  during  this  phase  will 
help  you  manage  time,  cost,  quality,  changes,  risk,  and  related  issues.  They  will  also  help  you  control  staff  and 
external  suppliers  to  ensure  that  you  deliver  the  project  on  time,  within  budget,  and  within  schedule. 

The  project  planning  phase  is  often  the  most  challenging  phase  for  a  project  manager,  as  you  need  to  make  an 
educated  guess  about  the  staff,  resources,  and  equipment  needed  to  complete  your  project.  You  may  also  need  to 
plan  your  communications  and  procurement  activities,  as  well  as  contract  any  third-party  suppliers. 

The  purpose  of  the  project  planning  phase  is  to: 

•  Establish  business  requirements 

•  Establish  cost,  schedule,  list  of  deliverables,  and  delivery  dates 

•  Establish  resources  plans 

•  Obtain  management  approval  and  proceed  to  the  next  phase 
The  basic  processes  of  project  planning  are: 

•  Scope  planning  -  specifying  the  in-scope  requirements  for  the  project  to  facilitate  creating  the  work  break¬ 
down  structure 

•  Preparation  of  the  work  breakdown  structure  -  spelling  out  the  breakdown  of  the  project  into  tasks  and  sub¬ 
tasks 

•  Project  schedule  development  -  listing  the  entire  schedule  of  the  activities  and  detailing  their  sequence  of 


64 


8.  OVERVIEW  OF  PROJECT  PLANNING  •  65 


implementation 

•  Resource  planning  -  indicating  who  will  do  what  work,  at  which  time,  and  if  any  special  skills  are  needed 
to  accomplish  the  project  tasks 

•  Budget  planning  -  specifying  the  budgeted  cost  to  be  incurred  at  the  completion  of  the  project 

•  Procurement  planning  -  focusing  on  vendors  outside  your  company  and  subcontracting 

•  Risk  management  -  planning  for  possible  risks  and  considering  optional  contingency  plans  and  mitigation 
strategies 

•  Quality  planning  -  assessing  quality  criteria  to  be  used  for  the  project 

•  Communication  planning  -  designing  the  communication  strategy  with  all  project  stakeholders 

The  planning  phase  refines  the  project’s  objectives,  which  were  gathered  during  the  initiation  phase.  It  includes 
planning  the  steps  necessary  to  meet  those  objectives  by  further  identifying  the  specific  activities  and  resources 
required  to  complete  the  project.  Now  that  these  objectives  have  been  recognized,  they  must  be  clearly  articulated, 
detailing  an  in-depth  scrutiny  of  each  recognized  objective.  With  such  scrutiny,  our  understanding  of  the  objective 
may  change.  Often  the  very  act  of  trying  to  describe  something  precisely  gives  us  a  better  understanding  of  what 
we  are  looking  at.  This  articulation  serves  as  the  basis  for  the  development  of  requirements.  What  this  means  is 
that  after  an  objective  has  been  clearly  articulated,  we  can  describe  it  in  concrete  (measurable)  terms  and  identify 
what  we  have  to  do  to  achieve  it.  Obviously,  if  we  do  a  poor  job  of  articulating  the  objective,  our  requirements 
will  be  misdirected  and  the  resulting  project  will  not  represent  the  true  need. 

Users  will  often  begin  describing  their  objectives  in  qualitative  language.  The  project  manager  must  work  with 
the  user  to  provide  quantifiable  definitions  to  those  qualitative  terms.  These  quantifiable  criteria  include  schedule, 
cost,  and  quality  measures.  In  the  case  of  project  objectives,  these  elements  are  used  as  measurements  to  determine 
project  satisfaction  and  successful  completion.  Subjective  evaluations  are  replaced  by  actual  numeric  attributes. 

Example  1 

A  web  user  may  ask  for  a  fast  system.  The  quantitative  requirement  should  be  all  screens  must  load  in  under 
three  seconds.  Describing  the  time  limit  during  which  the  screen  must  load  is  specific  and  tangible.  For  that  rea¬ 
son,  you’ll  know  that  the  requirement  has  been  successfully  completed  when  the  objective  has  been  met. 

Example  2 

Let’s  say  that  your  company  is  going  to  produce  a  holiday  batch  of  eggnog.  Your  objective  statement  might  be 
stated  this  way:  Christmas  Cheer,  Inc.  will  produce  two  million  cases  of  holiday  eggnog,  to  be  shipped  to  our  dis¬ 
tributors  by  October  30,  at  a  total  cost  of  $1.5  million  or  less.  The  objective  criteria  in  this  statement  are  clearly 
stated  and  successful  fulfillment  can  easily  be  measured.  Stakeholders  will  know  that  the  objectives  are  met  when 
the  two  million  cases  are  produced  and  shipped  by  the  due  date  within  the  budget  stated. 

When  articulating  the  project  objectives  you  should  follow  the  SMART  rule: 


Specific  -  get  into  the  details.  Objectives  should  be  specific  and  written  in  clear,  concise,  and  under¬ 
standable  terms. 
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•  Measurable  -  use  quantitative  language.  You  need  to  know  when  you  have  successfully  completed  the  task. 

•  Acceptable  -  agreed  with  the  stakeholders. 

•  Realistic  -  in  terms  of  achievement.  Objectives  that  are  impossible  to  accomplish  are  not  realistic  and  not 
attainable.  Objectives  must  be  centered  in  reality. 

•  Time  based  -  deadlines  not  durations.  Objectives  should  have  a  time  frame  with  an  end  date  assigned  to 
them. 

If  you  follow  these  principles,  you’ll  be  certain  that  your  objectives  meet  the  quantifiable  criteria  needed  to  mea¬ 
sure  success. 


Attribution 

This  chapter  of  Project  Management  is  a  derivative  copy  of  Project  Management  by  Merrie  Barron  and  Andrew 
Barron  licensed  under  Creative  Commons  Attribution  3.0  Unported 
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You  always  want  to  know  exactly  what  work  has  to  be  done  before  you  start  it.  You  have  a  collection  of  team 
members,  and  you  need  to  know  exactly  what  they’re  going  to  do  to  meet  the  project’s  objectives.  The  scope  plan¬ 
ning  process  is  the  very  first  thing  you  do  to  manage  your  scope.  Project  scope  planning  is  concerned  with  the 
definition  of  all  the  work  needed  to  successfully  meet  the  project  objectives.  The  whole  idea  here  is  that  when  you 
start  the  project,  you  need  to  have  a  clear  picture  of  all  the  work  that  needs  to  happen  on  your  project,  and  as  the 
project  progresses,  you  need  to  keep  that  scope  up  to  date  and  written  down  in  the  project’s  scope  management 
plan. 


Defining  the  Scope 

You  already  have  a  head  start  on  refining  the  project’s  objectives  in  quantifiable  terms,  but  now  you  need  to  plan 
further  and  write  down  all  the  intermediate  and  final  deliverables  that  you  and  your  team  will  produce  over  the 
course  of  the  project.  Deliverables  include  everything  that  you  and  your  team  produce  for  the  project  (i.e.,  any¬ 
thing  that  your  project  will  deliver).  The  deliverables  for  your  project  include  all  of  the  products  or  services  that 
you  and  your  team  are  performing  for  the  client,  customer,  or  sponsor.  They  include  every  intermediate  docu¬ 
ment,  plan,  schedule,  budget,  blueprint,  and  anything  else  that  will  be  made  along  the  way,  including  all  of  the 
project  management  documents  you  put  together.  Project  deliverables  are  tangible  outcomes,  measurable  results, 
or  specific  items  that  must  be  produced  to  consider  either  the  project  or  the  project  phase  completed.  Intermediate 
deliverables,  like  the  objectives,  must  be  specific  and  verifiable. 

All  deliverables  must  be  described  in  a  sufficient  level  of  detail  so  that  they  can  be  differentiated  from  related 
deliverables.  For  example: 

•  A  twin  engine  plane  versus  a  single  engine  plane 

•  A  red  marker  versus  a  green  marker 

•  A  daily  report  versus  a  weekly  report 

•  A  departmental  solution  versus  an  enterprise  solution 
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One  of  the  project  manager’s  primary  functions  is  to  accurately  document  the  deliverables  of  the  project  and  then 
manage  the  project  so  that  they  are  produced  according  to  the  agreed-on  criteria.  Deliverables  are  the  output  of 
each  development  phase,  described  in  a  quantifiable  way. 


Project  Requirements 

After  all  the  deliverables  are  identified,  the  project  manager  needs  to  document  all  the  requirements  of  the  project. 
Requirements  describe  the  characteristics  of  the  final  deliverable,  whether  it  is  a  product  or  a  service.  They 
describe  the  required  functionality  that  the  final  deliverable  must  have  or  specific  conditions  the  final  deliverable 
must  meet  in  order  to  satisfy  the  objectives  of  the  project.  A  requirement  is  an  objective  that  must  be  met.  The 
project’s  requirements,  defined  in  the  scope  plan,  describe  what  a  project  is  supposed  to  accomplish  and  how  the 
project  is  supposed  to  be  created  and  implemented.  Requirements  answer  the  following  questions  regarding  the 
as- is  and  to-be  states  of  the  business:  who,  what,  where,  when,  how  much,  and  how  does  a  business  process  work? 

Requirements  may  include  attributes  like  dimensions,  ease  of  use,  color,  specific  ingredients,  and  so  on.  If  we  go 
back  to  the  example  of  the  company  producing  holiday  eggnog,  one  of  the  major  deliverables  is  the  cartons  that 
hold  the  eggnog.  The  requirements  for  that  deliverable  may  include  carton  design,  photographs  that  will  appear 
on  the  carton,  color  choices,  etc. 

Requirements  specify  what  the  final  project  deliverable  should  look  like  and  what  it  should  do.  Requirements 
must  be  measurable,  testable,  related  to  identified  business  needs  or  opportunities,  and  defined  to  a  level  of  detail 
sufficient  for  system  design.  They  can  be  divided  into  six  basic  categories:  functional,  non-functional,  technical, 
business,  user,  and  regulatory  requirements. 

Functional  Requirements 

Functional  requirements  describe  the  characteristics  of  the  final  deliverable  in  ordinary  non-technical  language. 
They  should  be  understandable  to  the  customers,  and  the  customers  should  play  a  direct  role  in  their  development. 
Functional  requirements  are  what  you  want  the  deliverable  to  do. 

Vehicle  Example 

If  you  were  buying  vehicles  for  a  business,  your  functional  requirement  might  be:  “The  vehicles  should  be  able  to 
take  up  to  a  one  ton  load  from  a  warehouse  to  a  shop.” 

Computer  System  Example 

For  a  computer  system  you  may  define  what  the  system  is  to  do:  “The  system  should  store  all  details  of  a  cus¬ 
tomer’s  order.” 

The  important  point  to  note  is  that  what  is  wanted  is  specified  and  not  how  it  will  be  delivered. 

Non-Functional  Requirements 

Non-functional  requirements  specify  criteria  that  can  be  used  to  judge  the  final  product  or  service  that  your  project 
delivers.  They  are  restrictions  or  constraints  to  be  placed  on  the  deliverable  and  how  to  build  it.  Their  purpose  is 
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to  restrict  the  number  of  solutions  that  will  meet  a  set  of  requirements.  Using  the  vehicle  example,  the  functional 
requirement  is  for  a  vehicle  to  take  a  load  from  a  warehouse  to  a  shop.  Without  any  constraints,  the  solutions  being 
offered  might  result  in  anything  from  a  small  to  a  large  truck.  Non-functional  requirements  can  be  split  into  two 
types:  performance  and  development. 

To  restrict  the  types  of  solutions,  you  might  include  these  performance  constraints: 

•  The  purchased  trucks  should  be  American-made  trucks  due  to  government  incentives. 

•  The  load  area  must  be  covered. 

•  The  load  area  must  have  a  height  of  at  least  10  feet. 

Similarly,  for  the  computer  system  example,  you  might  specify  values  for  the  generic  types  of  performance  con¬ 
straints: 

•  The  response  time  for  information  is  displayed  on  the  screen  for  the  user. 

•  The  number  of  hours  a  system  should  be  available. 

•  The  number  of  records  a  system  should  be  able  to  hold. 

•  The  capacity  for  growth  of  the  system  should  be  built  in. 

•  The  length  of  time  a  record  should  be  held  for  auditing  purposes. 

For  the  customer  records  example,  the  constraints  might  be: 

•  The  system  should  be  available  from  9  a.m.  to  5  p.m.Monday  to  Friday. 

•  The  system  should  be  able  to  hold  100,000  customer  records  initially. 

•  The  system  should  be  able  to  add  10,000  records  a  year  for  10  years. 

•  A  record  should  be  fully  available  on  the  system  for  at  least  seven  years. 

One  important  point  with  these  examples  is  that  they  restrict  the  number  of  solution  options  that  are  offered  to  you 
by  the  developer.  In  addition  to  the  performance  constraints,  you  may  include  some  development  constraints. 

There  are  three  general  types  of  non-functional  development  constraints: 

•  Time:  When  a  deliverable  should  be  delivered 

•  Resource:  How  much  money  is  available  to  develop  the  deliverable 

•  Quality:  Any  standards  that  are  used  to  develop  the  deliverable,  development  methods,  etc. 

Technical  Requirements 

Technical  requirements  emerge  from  the  functional  requirements  to  answer  the  questions:  how  will  the  problem 
be  solved  this  time  and  will  it  be  solved  technologically  and/or  procedurally?  They  specify  how  the  system  needs 
to  be  designed  and  implemented  to  provide  required  functionality  and  fulfill  required  operational  characteristics. 

For  example,  in  a  software  project,  the  functional  requirements  may  stipulate  that  a  database  system  will  be  devel- 
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oped  to  allow  access  to  financial  data  through  a  remote  terminal.  The  corresponding  technical  requirements  would 
spell  out  the  required  data  elements,  the  language  in  which  the  database  management  system  will  be  written 
(due  to  existing  knowledge  in-house),  the  hardware  on  which  the  system  will  run  (due  to  existing  infrastructure), 
telecommunication  protocols  that  should  be  used,  and  so  forth. 

Business  Requirements 

Business  requirements  are  the  needs  of  the  sponsoring  organization,  always  from  a  management  perspective. 
Business  requirements  are  statements  of  the  business  rationale  for  the  project.  They  are  usually  expressed  in  broad 
outcomes,  satisfying  the  business  needs,  rather  than  specific  functions  the  system  must  perform.  These  require¬ 
ments  grow  out  of  the  vision  for  the  product  that,  in  turn,  is  driven  by  mission  (or  business)  goals  and  objectives. 

User  Requirements 

User  requirements  describe  what  the  users  need  to  do  with  the  system  or  product.  The  focus  is  on  the  user  expe¬ 
rience  with  the  system  under  all  scenarios.  These  requirements  are  the  input  for  the  next  development  phases: 
user-interface  design  and  system  test  cases  design. 

Regulatory  requirements 

Regulatory  requirements  can  be  internal  or  external  and  are  usually  non-negotiable.  They  are  the  restrictions, 
licenses,  and  laws  applicable  to  a  product  or  business  that  are  imposed  by  the  government. 

An  Example  of  Requirements 

Automated  teller  machines  (ATMs)  can  be  used  to  illustrate  a  wide  range  of  requirements  (Figure  9.1).  What  are 
some  of  the  physical  features  of  these  machines,  and  what  kinds  of  functions  do  they  perform  for  the  bank’s  cus¬ 
tomers?  Why  did  banks  put  these  systems  in  place?  What  are  the  high-level  business  requirements? 


Figure  9.1  Automated  Teller  Machine.  ATM  (https://flic.kr/p/ 
6bHE21)  by  megawatts86  (https://www.flickr.com/photos/ 
32317927@N07/)  under  CC-BY-SA  license 
(https://creativecommons.Org/licenses/by-sa/2.0/) 


The  following  represents  one  possible  example  of  each  type  of  requirement  as  they  would  be  applied  to  a  bank’s 
external  ATM. 

•  ATM  functional  requirement:  The  system  will  enable  the  user  to  select  whether  or  not  to  produce  a  hard¬ 
copy  transaction  receipt  before  completing  a  transaction. 

•  ATM  non-functional  requirement:  All  displays  will  be  in  white,  14-point  Arial  text  on  black  background. 

•  ATM  technical  requirement:  The  ATM  system  will  connect  seamlessly  to  the  existing  customer’s  database. 

•  ATM  user  requirement:  The  system  will  complete  a  standard  withdrawal  from  a  personal  account,  from 
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login  to  cash,  in  less  than  two  minutes. 

•  ATM  business  requirement:  By  providing  superior  service  to  our  retail  customers,  Monumental  Bank’s 
ATM  network  will  allow  us  to  increase  associated  service  fee  revenue  by  10%  annually  on  an  ongoing 
basis. 

•  ATM  regulatory  requirement:  All  ATMs  will  connect  to  standard  utility  power  sources  within  their  civic 
jurisdiction,  and  be  supplied  with  an  uninterrupted  power  source  approved  by  the  company. 

The  effective  specification  of  requirements  is  one  of  the  most  challenging  undertakings  project  managers  face. 
Inadequately  specified  requirements  will  guarantee  poor  project  results. 

Documenting  requirements  is  much  more  than  just  the  process  of  writing  down  the  requirements  as  the  user  sees 
them;  it  should  cover  not  only  what  decisions  have  been  made,  but  why  they  have  been  made,  as  well.  Under¬ 
standing  the  reasoning  that  was  used  to  arrive  at  a  decision  is  critical  in  avoiding  repetition.  For  example,  the  fact 
that  a  particular  feature  has  been  excluded,  because  it  is  simply  not  feasible,  needs  to  be  recorded.  If  it  is  not,  then 
the  project  risks  wasted  work  and  repetition,  when  a  stakeholder  requests  the  feature  be  reinstated  during  devel¬ 
opment  or  testing. 

Once  the  requirements  are  documented,  have  the  stakeholders  sign  off  on  their  requirements  as  a  confirmation  of 
what  they  desire. 

While  the  project  manager  is  responsible  for  making  certain  the  requirements  are  documented,  it  does  not  mean 
that  the  project  manager  performs  this  task.  The  project  manager  enlists  the  help  of  all  the  stakeholders  (business 
analysts,  requirement  analysts,  business  process  owners,  customers  and  other  team  members)  to  conduct  the  dis¬ 
cussions,  brain-storming,  and  interviews,  and  to  document  and  sign  off  the  requirements.  The  project  manager  is 
responsible  only  for  enabling  the  process  and  facilitating  it.  If  the  project  manager  feels  that  the  quality  of  the 
document  is  questionable,  his  or  her  duty  is  to  stop  the  development  process. 

The  project  manager  reviews  the  requirements,  incorporates  them  into  the  project  documentation  library,  and  uses 
them  as  an  input  for  the  project  plan. 

Software  Requirements  Fundamentals 

This  section  refers  to  requirements  of  “software”  because  it  is  concerned  with  problems  to  be  addressed  by  soft¬ 
ware.  A  software  requirement  is  a  property  that  must  be  exhibited  by  software  developed  or  adapted  to  solve  a 
particular  problem.  The  problem  may  be  to  automate  part  of  a  task  of  someone  who  will  use  the  software,  to  sup¬ 
port  the  business  processes  of  the  organization  that  has  commissioned  the  software,  to  correct  shortcomings  of 
existing  software,  to  control  a  device,  etc.  The  functioning  of  users,  business  processes,  and  devices  is  typically 
complex.  Therefore,  the  requirements  on  particular  software  are  typically  a  complex  combination  of  requirements 
from  different  people  at  different  levels  of  an  organization  and  from  the  environment  in  which  the  software  will 
operate. 

An  essential  property  of  all  software  requirements  is  that  they  be  verifiable.  It  may  be  difficult  or  costly  to  verify 
certain  software  requirements.  For  example,  verification  of  the  throughput  requirement  on  a  call  center  may  neces¬ 
sitate  the  development  of  simulation  software.  Both  the  software  requirements  and  software  quality  personnel 
must  ensure  that  the  requirements  can  be  verified  within  the  available  resource  constraints. 
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Requirements  have  other  attributes  in  addition  to  the  behavioral  properties  that  they  express.  Common  examples 
include  a  priority  rating  to  enable  trade-offs  in  the  face  of  finite  resources  and  a  status  value  to  enable  project 
progress  to  be  monitored.  Typically,  software  requirements  are  uniquely  identified  so  that  they  can  be  monitored 
over  the  entire  software  life  cycle. 

Measuring  Requirements 

As  a  practical  matter,  it  is  typically  useful  to  have  some  concept  of  the  volume  of  the  requirements  for  a  particular 
software  product.  This  number  is  useful  in  evaluating  the  size  of  a  change  in  requirements,  in  estimating  the  cost 
of  a  development  or  maintenance  task,  or  simply  in  using  it  as  the  denominator  in  other  measurements  (see  Table 

9.1). 


Table  9.1:  Table  of  Measuring  Requirements. 
Source:  A  Watt. 


Scope  Inputs 

The  project  manager  gathers  initial  project  facts  from  the  project  charter.  In  addition,  background  information  on 
the  stakeholder’s  workplace,  existing  business  model  and  rules,  etc.  assist  in  creating  the  vision  of  the  final  prod¬ 
uct/service,  and  consequently,  the  project  scope  (see  Figure  9.2). 


Figure  9.2:  Scope  input-output  by  Flaming  Sevens  (http://en.wikibooks.Org/wiki/File:ScopeIO.JPG)  in  the 
Public  Domain  (http://en.wikipedia.org/wiki/Pubbc_domain). 


Techniques 

Certainly  being  a  seasoned  project  manager  broadens  the  repertoire  of  one’s  scope  planning  techniques.  An  expe¬ 
rienced  project  manager  can  draw  on  past  experiences  with  like  projects  to  determine  the  work  that  is  realistically 
doable,  given  time  and  cost  constraints,  for  a  current  project.  Communication  and  negotiation  skills  are  a  “must- 
have”  as  well.  Project  managers  need  to  educate  stakeholders  about  the  project  impacts  of  some  requirements. 
Adding  complexity  to  a  project  may  require  more  staff,  time,  and/or  money.  It  may  also  have  an  impact  on  project 
quality.  Some  aspects  of  the  project  may  be  unfeasible  -  stakeholders  need  to  know  this  so  they  can  adjust  their 
vision  or  prepare  for  future  challenges. 

Gathering  requirements  is  part  of  scope  definition,  and  it  can  be  done  using  one  or  more  of  following  techniques: 


•  Interviews 
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•  Focus  groups 

•  Facilitated  groups  such  as  JAD  (joint  application  development) 

•  Group  creativity  techniques:  brainstorming,  nominal  groups,  delphi,  mind  map,  affinity  diagnostics 

•  Prototyping 

•  Observation 

•  Questions  and  surveys 

•  Group  decision-making  techniques:  unanimity,  majority,  plurality,  dictatorship 


Requirements  Traceability  Matrix 

The  requirements  traceability  matrix  is  a  table  that  links  requirements  to  their  origin  and  traces  them  throughout 
the  project  life  cycle.  The  implementation  of  a  requirements  traceability  matrix  helps  ensure  that  each  requirement 
adds  business  value  by  linking  it  to  the  business  and  project  objectives.  It  provides  a  means  to  track  requirements 
throughout  the  project  life  cycle,  helping  to  ensure  that  requirements  approved  in  the  requirements  documentation 
are  delivered  at  the  end  of  the  project.  Finally,  it  provides  a  structure  for  managing  changes  to  the  product  scope. 
This  process  includes,  but  is  not  limited  to,  tracking: 

•  Requirements  to  business  needs,  opportunities,  goals,  and  objectives 

•  Requirements  to  project  objectives 

•  Requirements  to  project  scope/work  breakdown  structure  deliverables 

•  Requirements  to  product  design 

•  Requirements  to  product  development 

•  Requirements  to  test  strategy  and  test  scenarios 

•  High-level  requirements  to  more  detailed  requirements 

Attributes  associated  with  each  requirement  can  be  recorded  in  the  requirements  traceability  matrix.  These  attrib¬ 
utes  help  to  define  key  information  about  the  requirement.  Typical  attributes  used  in  the  requirements  traceability 
matrix  may  include  a  unique  identifier,  a  textual  description  of  the  requirement,  the  rationale  for  inclusion,  owner, 
source,  priority,  version,  current  status  (such  as  active,  cancelled,  deferred,  added,  approved),  and  date  completed. 
Additional  attributes  to  ensure  that  the  requirement  has  met  stakeholders’  satisfaction  may  include  stability,  com¬ 
plexity,  and  acceptance  criteria. 

Matrix  Fields 

These  are  suggestions  only  and  will  vary  based  on  organizational  and  project  requirements. 

•  A  unique  identification  number  containing  the  general  category  of  the  requirement  (e.g.,  SYSADM)  and  a 
number  assigned  in  ascending  order  (e.g.,  1.0,  1.1,  1.2) 

•  Requirement  statement 

•  Requirement  source  (conference,  configuration  control  board,  task  assignment,  etc.) 
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•  Software  requirements  specification/functional  requirements  document  paragraph  number  containing  the 
requirement 

•  Design  specification  paragraph  number  containing  the  requirement 

•  Program  module  containing  the  requirement 

•  Test  specification  containing  the  requirement  test 

•  Test  case  number(s)  where  requirement  is  to  be  tested  (optional) 

•  Verification  of  successful  testing  of  requirements 

•  Modification  field  (If  a  requirement  was  changed,  eliminated,  or  replaced,  indicate  disposition  and  authority 
for  modification.) 

•  Remarks 

Requirements  Traceability  Matrix  by  DHWiki  licensed  under  Creative  Commons  Attribution-Noncommercial-No 
Derivative  Works  3.0  United  States  License. 


Work  Breakdown  Structure 

Now  that  we  have  the  deliverables  and  requirements  well  defined,  the  process  of  breaking  down  the  work  of 
the  project  via  a  work  breakdown  structure  (WBS)  begins.  The  WBS  defines  the  scope  of  the  project  and  breaks 
the  work  down  into  components  that  can  be  scheduled,  estimated,  and  easily  monitored  and  controlled.  The  idea 
behind  the  WBS  is  simple:  you  subdivide  a  complicated  task  into  smaller  tasks,  until  you  reach  a  level  that  can¬ 
not  be  further  subdivided.  Anyone  familiar  with  the  arrangements  of  folders  and  files  in  a  computer  memory  or 
who  has  researched  their  ancestral  family  tree  should  be  familiar  with  this  idea.  You  stop  breaking  down  the  work 
when  you  reach  a  low  enough  level  to  perform  an  estimate  of  the  desired  accuracy.  At  that  point,  it  is  usually 
easier  to  estimate  how  long  the  small  task  will  take  and  how  much  it  will  cost  to  perform  than  it  would  have  been 
to  estimate  these  factors  at  the  higher  levels.  Each  descending  level  of  the  WBS  represents  an  increased  level  of 
detailed  definition  of  the  project  work. 

WBS  describes  the  products  or  services  to  be  delivered  by  the  project  and  how  they  are  decomposed  and  related. 
It  is  a  deliverable-oriented  decomposition  of  a  project  into  smaller  components.  It  defines  and  groups  a  project’s 
discrete  work  elements  in  a  way  that  helps  organize  and  define  the  total  work  scope  of  the  project. 

A  WBS  also  provides  the  necessary  framework  for  detailed  cost  estimating  and  control,  along  with  providing 
guidance  for  schedule  development  and  control. 


Overview 

WBS  is  a  hierarchical  decomposition  of  the  project  into  phases,  deliverables,  and  work  packages.  It  is  a  tree  struc¬ 
ture,  which  shows  a  subdivision  of  effort  required  to  achieve  an  objective  (e.g.,  a  program,  project,  and  contract). 
In  a  project  or  contract,  the  WBS  is  developed  by  starting  with  the  end  objective  and  successively  subdividing 
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it  into  manageable  components  in  terms  of  size,  duration,  and  responsibility  (e.g.,  systems,  subsystems,  compo¬ 
nents,  tasks,  subtasks,  and  work  packages),  which  include  all  steps  necessary  to  achieve  the  objective. 

The  WBS  creation  involves: 

•  Listing  all  the  project  outputs  (deliverables  and  other  direct  results) 

•  Identifying  all  the  activities  required  to  deliver  the  outputs 

•  Subdividing  these  activities  into  subactivities  and  tasks 

•  Identifying  the  deliverable  and  milestone(s)  of  each  task 

•  Identifying  the  time  usage  of  all  the  resources  (personnel  and  material)  required  to  complete  each  task 
The  purpose  of  developing  a  WBS  is  to: 

•  Allow  easier  management  of  each  component 

•  Allow  accurate  estimation  of  time,  cost,  and  resource  requirements 

•  Allow  easier  assignment  of  human  resources 

•  Allow  easier  assignment  of  responsibility  for  activities 

Example  of  a  WBS 

If  I  want  to  clean  a  room,  I  might  begin  by  picking  up  clothes,  toys,  and  other  things  that  have  been  dropped  on 
the  floor.  I  could  use  a  vacuum  cleaner  to  get  dirt  out  of  the  carpet.  I  might  take  down  the  curtains  and  take  them 
to  the  cleaners,  and  then  dust  the  furniture.  All  of  these  tasks  are  subtasks  performed  to  clean  the  room.  As  for 
vacuuming  the  room,  I  might  have  to  get  the  vacuum  cleaner  out  of  the  closet,  connect  the  hose,  empty  the  bag, 
and  put  the  machine  back  in  the  closet.  These  are  smaller  tasks  to  be  performed  in  accomplishing  the  subtask 
called  vacuuming.  Figure  9.3  shows  how  this  might  be  portrayed  in  WBS  format. 


Figure  9.3:  A  WBS  for  cleaning  a  room 
Source:  Project  Management  Skills  for  All  Careers 


It  is  very  important  to  note  that  we  do  not  worry  about  the  sequence  in  which  the  work  is  performed  or  any  depen¬ 
dencies  between  the  tasks  when  we  do  a  WBS.  That  will  be  worked  out  when  we  develop  the  schedule.  For  exam¬ 
ple,  under  3.0  Vacuum,  it  would  be  obvious  that  3.3  Vacuum  carpet  would  be  performed  after  3.4  Connect  hose 
and  plug!  However,  you  will  probably  find  yourself  thinking  sequentially,  as  it  seems  to  be  human  nature  to  do  so. 
The  main  idea  of  creating  a  WBS  is  to  capture  all  of  the  tasks,  irrespective  of  their  order.  So  if  you  find  yourself 
and  other  members  of  your  team  thinking  sequentially,  don’t  be  too  concerned,  but  don’t  get  hung  up  on  trying  to 
diagram  the  sequence  or  you  will  slow  down  the  process  of  task  identification.  A  WBS  can  be  structured  any  way 
it  makes  sense  to  you  and  your  project.  In  practice,  the  chart  structure  is  used  quite  often  but  it  can  be  composed 
in  outline  form  as  well  (Figure  9.4). 
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Figure  9.4:  Clean  Room  in  an  outline  view. 
Source:  Project  Management  Skills  for  All 
Careers 


You’ll  notice  that  each  element  at  each  level  of  the  WBS  in  both  figures  is  assigned  a  unique  identifier.  This 
unique  identifier  is  typically  a  number,  and  it’s  used  to  sum  and  track  costs,  schedules,  and  resources  associated 
with  WBS  elements.  These  numbers  are  usually  associated  with  the  corporation’s  chart  of  accounts,  which  is  used 
to  track  costs  by  category.  Collectively,  these  numeric  identifiers  are  known  as  the  code  of  accounts. 


There  are  also  many  ways  you  can  organize  the  WBS.  For  example,  it  can  be  organized  by  either  deliverable  or 
phase.  The  major  deliverables  of  the  project  are  used  as  the  first  level  in  the  WBS.  For  example,  if  you  are  doing 
a  multimedia  project  the  deliverables  might  include  producing  a  book,  CD,  and  a  DVD  (Figure  9.5). 


Figure  9.5:  A  WBS  for  a  multimedia  project 
Source:  Project  Management  Skills  for  All  Careers 


Many  projects  are  structured  or  organized  by  project  phases  (Figure  9.6).  Each  phase  would  represent  the  first 
level  of  the  WBS  and  their  deliverables  would  be  the  next  level  and  so  on. 


Figure  9.6:  WBS  Project  Phases 

Source:  Project  Management  Skills  for  All  Careers 


The  project  manager  is  free  to  determine  the  number  of  levels  in  the  WBS  based  on  the  complexity  of  the  project. 
You  need  to  include  enough  levels  to  accurately  estimate  project  time  and  costs  but  not  so  many  levels  that  are 
difficult  to  distinguish  between  components.  Regardless  of  the  number  of  levels  in  a  WBS,  the  lowest  level  is 
called  a  work  package. 

Work  packages  are  the  components  that  can  be  easily  assigned  to  one  person  or  a  team  of  people,  with  clear 
accountability  and  responsibility  for  completing  the  assignment.  The  work-package  level  is  where  time  estimates, 
cost  estimates,  and  resource  estimates  are  determined. 


100  Percent  Rule 


The  100  percent  rule  is  the  most  important  criterion  in  developing  and  evaluating  the  WBS.  The  rule  states  that 
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each  decomposed  level  (child)  must  represent  100  percent  of  the  work  applicable  to  the  next  higher  (parent)  ele¬ 
ment.  In  other  words,  if  each  level  of  the  WBS  follows  the  100  percent  rule  down  to  the  activities,  then  we  are 
confident  that  100  percent  of  the  activities  will  have  been  identified  when  we  develop  the  project  schedule.  When 
we  create  the  budget  for  our  project,  100  percent  of  the  costs  or  resources  required  will  be  identified. 


Scope  Statement 

Scope  statements  may  take  many  forms  depending  on  the  type  of  project  being  implemented  and  the  nature  of  the 
organization.  The  scope  statement  details  the  project  deliverables  and  describes  the  major  objectives.  The  objec¬ 
tives  should  include  measurable  success  criteria  for  the  project. 

A  scope  statement  captures,  in  very  broad  terms,  the  product  of  the  project:  for  example,  “development  of  a  soft¬ 
ware-based  system  to  capture  and  track  orders  for  software.”  A  scope  statement  should  also  include  the  list  of 
users  using  the  product,  as  well  as  the  features  in  the  resulting  product. 

As  a  baseline  scope  statements  should  contain: 

•  The  project  name 

•  The  project  charter 

•  The  project  owner,  sponsors,  and  stakeholders 

•  The  problem  statement 

•  The  project  goals  and  objectives 

•  The  project  requirements 

•  The  project  deliverables 

•  The  project  non-goals  (what  is  out  of  scope) 

•  Milestones 

•  Cost  estimates 

In  more  project-oriented  organizations,  the  scope  statement  may  also  contain  these  and  other  sections: 

•  Project  scope  management  plan 

•  Approved  change  requests 

•  Project  assumptions  and  risks 

•  Project  acceptance  criteria 

Attribution 

This  chapter  of  Project  Management  is  a  derivative  copy  of  Project  Management  by  Merrie  Barron  and  Andrew 
Barron  licensed  under  Creative  Commons  Attribution  3.0  Unported,  Project  Management/PMBOK/Scope  Man¬ 
agement  and  Development  Cooperation  Handbook/Designing  and  Executing  Projects/Detailed  Planning  or  design 
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stage  by  Wikibooks  licensed  under  Creative  Commons  Attribution- ShareAlike  3.0  License,  Work  Breakdown 
Structure  by  Wikipedia  licensed  under  Creative  Commons  Attribution- ShareAlike  3.0  License.,  and  100  Percent 
Rule  by  Pabipedia  licensed  under  Creative  Commons  Attribution- ShareAlike  3.0  License. 


10.  Project  Schedule  Planning 


ADRIENNE  WATT 


In  order  to  develop  our  schedule,  we  first  need  to  define  the  activities,  sequence  them  in  the  right  order,  estimate 
the  resources  needed,  and  estimate  the  time  it  will  take  to  complete  the  tasks. 


Defining  Activities 

The  activity  definition  process  is  a  further  breakdown  of  the  work  package  elements  of  the  WBS.  It  documents  the 
specific  activities  needed  to  fulfill  the  deliverables  detailed  in  the  WBS.  These  activities  are  not  the  deliverables 
themselves  but  the  individual  units  of  work  that  must  be  completed  to  fulfill  the  deliverables.  Activity  definition 
uses  everything  we  already  know  about  the  project  to  divide  the  work  into  activities  that  can  be  estimated.  You 
might  want  to  look  at  all  the  lessons  learned  from  similar  projects  your  company  has  done  to  get  a  good  idea  of 
what  you  need  to  do  on  the  current  one. 

Expert  judgment  in  the  form  of  project  team  members  with  prior  experience  developing  project  scope  statements 
and  WBS  can  help  you  define  activities.  If  you  are  asked  to  manage  a  project  in  a  new  domain,  you  might  also  use 
experts  in  that  particular  field  to  help  define  tasks  so  you  can  understand  what  activities  are  going  to  be  involved. 
You  may  want  to  create  an  activity  list  and  then  have  the  expert  review  it  and  suggest  changes.  Alternatively,  you 
could  involve  the  expert  from  the  very  beginning  and  ask  to  have  an  activity  definition  conversation  with  him  or 
her  before  even  making  your  first  draft  of  the  list. 

Sometimes  you  start  a  project  without  knowing  a  lot  about  the  work  that  you’ll  be  doing  later.  Rolling-wave  plan¬ 
ning  lets  you  plan  and  schedule  only  the  portion  that  you  know  enough  about  to  plan  well.  When  you  don’t  know 
enough  about  a  project,  you  can  use  placeholders  for  the  unknown  portions  until  you  know  more.  These  are  extra 
items  that  are  put  at  high  levels  in  the  WBS  to  allow  you  to  plan  for  the  unknown. 


A  Case  Study 

Susan  and  Steve  have  decided  to  tie  the  knot,  but  they  don’t  have  much  time  to  plan  their  wedding.  They  want  the 
big  day  to  be  unforgettable.  They  want  to  invite  many  people  and  provide  a  great  time.  They’ve  always  dreamed 
of  a  June  wedding,  but  it’s  already  January.  Just  thinking  about  all  of  the  details  involved  is  overwhelming.  Susan 
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has  been  dreaming  of  the  big  day  since  she  was  12,  but  it  seems  that  there’s  so  little  time  for  all  the  tasks  to  be 
completed.  When  they  were  choosing  the  paper  for  the  invitations,  the  couple  realized  that  they  needed  help. 


Susan: 

Steve,  we  need  some  help. 

Steve 

Don’t  worry.  My  sister’s  wedding  planner  was  great.  Let  me 
give  her  a  call.  [Steve  calls  the  wedding  planner  Sally.] 

Wedding  Planner 

Hello  Susan  and  Steve. 

Steve 

We  want  everything  to  be  perfect. 

Susan 

There  is  so  much  to  do!  Invitations,  food,  guests,  and  music. 

Steve 

Oh  no,  we  haven’t  even  booked  a  place! 

Susan 

And  it  has  to  be  done  right.  We  can’t  print  the  invitations 
until  we  have  the  menu  planned.  We  can’t  do  the  seating 
arrangements  until  we  have  the  RSVPs.  We  aren’t  sure  what 
kind  of  band  to  get  for  the  reception,  or  should  it  be  a  DJ? 
We’re  just  overwhelmed. 

Steve 

My  sister  said  you  really  saved  her  wedding.  I  know  she 
gave  you  over  a  year  to  plan. 

Steve 

But  I’ve  always  dreamed  of  a  June  wedding,  and  I’m  not 
willing  to  give  that  up.  I  know  it’s  late,  but  Sally  can  you 
help  us? 

Wedding  Planner 

Take  it  easy,  guys.  I’ve  got  it  under  control.  We’ve  a  lot  of 
people  and  activities  to  get  under  control.  You  guys  really 
should  have  called  six  months  ago,  but  we’ll  still  make  this 
wedding  happen  on  time. 

Much  work  has  to  be  done  before  June.  First,  Sally  figures  out  what  work  needs  to  be  done.  She  starts  to  put 
together  a  to-do  list: 

•  Invitations 

•  Flowers 

•  Wedding  cake 

•  Dinner  menu 

•  Band 

Since  many  different  people  are  involved  in  the  making  of  the  wedding,  it  takes  much  planning  to  coordinate  all 
the  work  in  the  right  order  by  the  right  people  at  the  right  time.  Initially,  Sally  was  worried  that  she  didn’t  have 
enough  time  to  make  sure  that  everything  would  be  done  properly.  However,  she  knew  that  she  had  some  power¬ 
ful  time  management  tools  on  her  side  when  she  took  the  job,  and  these  tools  would  help  her  to  synchronize  all 
the  required  tasks. 
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To  get  started,  Sally  arranged  all  the  activities  in  a  work  breakdown  structure.  The  next  exercise  presents  part  of 
the  WBS  Sally  made  for  the  wedding. 

WBS  Exercise  (Solution  follows) 

Arrange  the  following  activities  into  the  WBS  (Figure  10.1)  to  show  how  the  work  items  decompose  into  activi¬ 
ties. 

•  Shop  for  shoes 

•  Create  guest  list 

•  Have  the  tailoring  and  fitting  done 

•  Shop  for  dress 

•  Find  caterer 

•  Cater  the  wedding 

•  Wait  for  RSVPs 

•  Mail  the  invitations 

•  Finalize  the  menu 

•  Print  the  invitations 

•  Choose  the  bouquet 
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Figure  10.1:  Work  breakdown  structure  (WBS)  based  on  project 
phase. 

Illustration  from  Barron  &  Barron  Project  Management  for 
Scientists  and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


Solution  to  Exercise:  Figure  10.2 
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Figure  10.2:  Work  breakdown  structure  (WBS)  based  on  project 
phase  -  solution. 

Illustration  from  Barron  &  Barron  Project  Management  for 
Scientists  and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


Activity  List 

Now  that  the  activity  definitions  for  the  work  packages  have  been  completed,  the  next  task  is  to  complete  the 
activity  list.  The  project  activity  list  is  a  list  of  everything  that  needs  to  be  done  to  complete  your  project,  includ¬ 
ing  all  the  activities  that  must  be  accomplished  to  deliver  each  work  package.  Next  you  want  to  define  the  activity 
attributes.  Here’s  where  the  description  of  each  activity  is  kept.  It  includes  all  the  information  you  need  to  figure 
out  plus  the  order  of  the  work.  Any  predecessor  activities,  successor  activities,  or  constraints  should  be  listed  in 
the  attributes  along  with  descriptions  and  any  other  information  about  resources  or  time  that  you  need  for  plan¬ 
ning.  The  three  main  kinds  of  predecessors  are  finish-to-start  (FS),  start-to-start  (SS),  and  finish-to-finish  (FF). 
The  most  common  kind  of  predecessor  is  the  finish-to-start.  It  means  that  one  task  needs  to  be  completed  before 
another  one  can  start.  When  you  think  of  predecessors,  this  is  what  you  usually  think  of;  one  thing  needs  to  end 
before  the  next  can  begin.  It’s  called  finish-to-start  because  the  first  activity’s  finish  leads  into  the  second  activ¬ 
ity’s  start  (Figure  10.3). 


Figure  10.3:  An  example  of  a  finish-to-start  (FS)  predecessor. 
Illustration  from  Barron  &  Barron  Project  Management  for 
Scientists  and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


The  start-to-start  predecessor  is  a  little  less  common,  but  sometimes  you  need  to  coordinate  activities  so  they 
begin  at  the  same  time  (Figure  10.4). 


Give  toast 

Serve  cake 

Figure  10.4:  An  example  of  a  start-to-start  (SS)  predecessor. 
Illustration  from  Barron  &  Barron  Project  Management  for  Scientists 
and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


The  finish-to-finish  predecessor  shows  activities  that  finish  at  the  same  time  (Figure  10.5). 
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Play  "Here  comes 
the  bride" 


Bride  walks  down 
the  aisle 


Figure  10.5:  An  example  of  a  finish-to-finish  (FF)  predecessor.  Illustration  from  Barron  & 

Barron  Project  Management  for  Scientists  and  Engineers,  http://cnx.org/content/collll20/ 

1.4/ 

It  is  possible  to  have  start-to-finish  (SF)  predecessors.  This  happens  when  activities  require  that  another  task  be 
started  before  the  successor  task  can  finish.  An  example  might  be  that  the  musicians  cannot  finish  playing  until 
the  guests  have  started  leaving  the  ceremony.  In  addition,  there  are  some  particular  types  of  predecessors  that  must 
be  considered. 

External  Predecessors 

Sometimes  your  project  will  depend  on  things  outside  the  work  you’re  doing.  For  the  wedding,  we  are  depending 
on  the  wedding  party  before  us  to  be  out  of  the  reception  hall  in  time  for  us  to  decorate.  The  decoration  of  the 
reception  hall  then  depends  on  that  as  an  external  predecessor. 

Discretionary  Predecessors 

These  are  usually  process-  or  procedure-driven  or  best-practice  techniques  based  on  past  experience.  In  the  wed¬ 
ding  example,  Steve  and  Susan  want  the  bridesmaids  to  arrive  at  the  reception  before  the  couple  arrives.  There’s 
no  necessity;  it  is  just  a  matter  of  preference. 

Mandatory  Predecessors 

You  can’t  address  an  invitation  that  hasn’t  been  printed  yet.  So  printing  invitations  is  a  mandatory  predecessor  for 
addressing  them.  Mandatory  predecessors  are  the  kinds  that  have  to  exist  just  because  of  the  nature  of  the  work. 


Leads  and  Lags 

Sometimes  you  need  to  give  some  extra  time  between  activities.  Lag  time  is  when  you  purposefully  put  a  delay 
between  the  predecessor  task  and  the  successor.  For  example,  when  the  bride  and  her  father  dance,  the  others  wait 
awhile  before  they  join  them  (Figure  10.6). 
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Bride  and  father  dance 

Everyone  else  dances 

Figure  10.6:  A  lag  means  making  sure  that  one  task  waits  a  while  before 
it  gets  started. 

Illustration  from  Barron  &  Barron  Project  Management  for  Scientists 
and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


Lead  time  is  when  you  give  a  successor  task  some  time  to  get  started  before  the  predecessor  finishes  (Figure 
10.7).  So  you  might  want  the  caterer  preparing  dessert  an  hour  before  everybody  is  eating  dinner. 


Serve  dinner 

Prepare  dessert 

Figure  10.7:  A  lead  is  when  you  let  a  task  get  started  before  its 
predecessor  is  done. 

Illustration  from  Barron  &  Barron  Project  Management  for 
Scientists  and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


Milestones 

All  of  the  important  checkpoints  of  your  project  are  tracked  as  milestones.  Some  of  them  could  be  listed  in  your 
contract  as  requirements  of  successful  completion;  some  could  just  be  significant  points  in  the  project  that  you 
want  to  keep  track  of.  The  milestone  list  needs  to  let  everyone  know  which  milestones  are  required  and  which  are 
not. 

Some  milestones  for  Susan  and  Steve’s  wedding  might  be: 

•  Invitations  sent 

•  Menu  finalized 

•  Location  booked 

•  Bridesmaids’  dresses  fitted 

As  you  figure  out  which  activities  will  need  to  be  done,  you  may  realize  that  the  scope  needs  to  change.  When 
that  happens,  you  need  to  create  a  change  request  and  send  it  through  the  change  control  system. 


Some  things  that  could  go  wrong: 
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Wedding  planner 

We  just  got  the  programs  back  from  the  printer  and  they’re  all 
wrong. 

Steve 

The  quartet  cancelled.  They  had  another  wedding  that  day. 

Susan 

Aunt  Jane  is  supposed  to  sing  at  the  service,  but  after  what  hap¬ 
pened  at  her  uncle’s  funeral,  I  think  I  want  someone  else  to  do  it. 

Steve 

Should  we  really  have  a  pan  flute  player?  I’m  beginning  to  think  it 
might  be  overkill. 

Susan 

Apparently!  Maybe  we  should  hold  off  on  printing  the  invitations 
until  these  things  are  worked  out. 

Wedding  Planner 

OK,  let’s  think  about  exactly  how  we  want  to  do  this.  I  think  we 
need  to  be  sure  about  how  we  want  the  service  to  go  before  we  do 
any  more  printing. 

The  Activity  Sequencing  Process 

Now  that  we  know  what  we  have  to  do  to  make  the  wedding  a  success,  we  need  to  focus  on  the  order  of  the  work. 
Sally  sat  down  with  all  of  the  activities  she  had  defined  for  the  wedding  and  decided  to  figure  out  exactly  how 
they  needed  to  happen.  That’s  where  she  used  the  activity  sequencing  process. 

The  activity  attribute  list  Sally  created  had  most  of  the  predecessors  and  successors  necessary  written  in  it.  This  is 
where  she  thought  of  what  comes  first,  second,  third,  etc.  Sally’s  milestone  list  had  major  pieces  of  work  written 
down,  and  there  were  a  couple  of  changes  to  the  scope  she  had  discovered  along  the  way  that  were  approved  and 
ready  to  go. 


Example  milestone  list:  Steve  and  Susan  had  asked  that  the  invitations  be  printed  at  least  three  months  in  advance  to 
be  sure  that  everyone  had  time  to  RSVP.  That’s  a  milestone  on  Sally’s  list. 

Example  change  request:  When  Sally  realized  that  Steve  and  Susan  were  going  to  need  another  limo  to  take  the 
bridesmaids  to  the  reception  hall,  she  put  that  change  through  change  control,  including  running  everything  by 
Susan’s  mother,  and  it  was  approved. 


Creating  the  Gantt  Chart 

A  Gantt  chart  is  a  type  of  bar  chart,  developed  by  Henry  Gantt,  that  illustrates  a  project  schedule.  Gantt  charts  are 
easy  to  read  and  are  commonly  used  to  display  schedule  activities.  These  charts  display  the  start  and  finish  dates  of 
the  terminal  elements  and  summary  elements  of  a  project.  Terminal  elements  and  summary  elements  comprise  the 
work  breakdown  structure  of  the  project.  Some  Gantt  charts  also  show  the  dependency  relationships  (i.e.,  prece¬ 
dence  network)  between  activities. 
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Gantt  charts  show  all  the  key  stages  of  a  project  and  their  duration  as  a  bar  chart,  with  the  time  scale  across  the 
top.  The  key  stages  are  placed  on  the  bar  chart  in  sequence,  starting  in  the  top  left  corner  and  ending  in  the  bot¬ 
tom  right  corner  (Figure  10.8).  A  Gantt  chart  can  be  drawn  quickly  and  easily  and  is  often  the  first  tool  a  project 
manager  uses  to  provide  a  rough  estimate  of  the  time  that  it  will  take  to  complete  the  key  tasks.  Sometimes  it  is 
useful  to  start  with  the  target  deadline  for  completion  of  the  whole  project,  because  it  is  soon  apparent  if  the  time 
scale  is  too  short  or  unnecessarily  long.  The  detailed  Gantt  chart  is  usually  constructed  after  the  main  objectives 
have  been  determined. 


Figure  10.8  Gantt  chart  for  directory  production  -  source:  http://labspace.open.ac.uk/mod/ 
resource/view.php?id=451673 


In  this  example  in  Figure  10.8,  key  stage  K  (Organize  distribution)  starts  at  week  23  so  that  its  end  point  coincides 
with  key  stage  L  (Distribute  directory).  However,  K  could  begin  as  early  as  week  17,  as  soon  as  key  stage  J  is 
completed.  Key  stage  K  is  therefore  said  to  have  “slack.”  Key  stage  H  (Agree  print  contract)  has  been  placed  to 
end  at  week  12.  However,  it  could  end  as  late  as  week  22,  because  key  stage  I  (Print  directory)  does  not  begin 
until  week  23.  Key  stage  H  is  therefore  said  to  have  “float.”  Float  time  can  be  indicated  on  the  chart  by  adding 
a  line  ahead  of  the  bar  to  the  latest  possible  end  point.  Slack  and  float  show  you  where  there  is  flexibility  in  the 
schedule,  and  this  can  be  useful  when  you  need  to  gain  time  once  the  project  is  up  and  running. 

You  can  add  other  information  to  a  Gantt  chart,  for  example: 

•  Milestones  could  be  indicated  by  using  a  symbol  such  as  a  diamond  or  triangle. 

•  Project  meetings  could  be  indicated  by  another  symbol  such  as  a  circle. 

•  Reviews  of  progress  could  be  indicated  by  a  square. 

For  a  complex  project,  you  may  decide  to  produce  a  separate  Gantt  chart  for  each  of  the  key  stages.  If  you  do  this 
shordy  before  each  key  stage  begins,  you  will  be  able  to  take  any  last-minute  eventualities  into  account.  These 
charts  provide  a  useful  tool  for  monitoring  and  control  as  the  project  progresses. 

Gantt  charts  are  relatively  easy  to  draw  by  hand,  but  this  doesn’t  offer  the  same  level  of  flexibility  during  moni¬ 
toring  that  you  would  get  from  a  software  package.  Various  programs  are  available  to  assist  project  managers  in 
scheduling  and  control.  Once  the  data  have  been  entered,  a  program  helps  you  to  work  on  “what  if”  scenarios, 
showing  what  might  happen  if  a  key  stage  is  delayed  or  speeded  up.  This  is  more  difficult  if  you  are  working 
manually. 
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Creating  the  Network  Diagram 

Many  project  managers  use  network  diagrams  when  scheduling  a  project.  The  network  diagram  is  a  way  to  visu¬ 
alize  the  interrelationships  of  project  activities.  Network  diagrams  provide  a  graphical  view  of  the  tasks  and  how 
they  relate  to  one  another.  The  tasks  in  the  network  are  the  work  packages  of  the  WBS.  All  of  the  WBS  tasks  must 
be  included  in  the  network  because  they  have  to  be  accounted  for  in  the  schedule.  Leaving  even  one  task  out  of 
the  network  could  change  the  overall  schedule  duration,  estimated  costs,  and  resource  allocation  commitments. 

The  first  step  is  to  arrange  the  tasks  from  your  WBS  into  a  sequence.  Some  tasks  can  be  accomplished  at  any 
time  throughout  the  project  where  other  tasks  depend  on  input  from  another  task  or  are  constrained  by  time  or 
resources. 


Figure  10.9:  The  relationship  between  the  work  breakdown 
structure  (WBS)  and  the  network  diagram. 

Illustration  from  Barron  &  Barron  Project  Management  for 
Scientists  and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


The  WBS  is  not  a  schedule,  but  it  is  the  basis  for  it.  The  network  diagram  is  a  schedule  but  is  used  primarily  to 
identify  key  scheduling  information  that  ultimately  goes  into  user-friendly  schedule  formats,  such  as  milestone 
and  Gantt  charts. 

The  network  diagram  provides  important  information  to  the  project  team.  It  provides  information  about  how  the 
tasks  are  related  (Figure  10.9),  where  the  risk  points  are  in  the  schedule,  how  long  it  will  take  as  currently  planned 
to  finish  the  project,  and  when  each  task  needs  to  begin  and  end. 

In  our  wedding  planner  example,  Sally  would  look  for  relationships  between  tasks  and  determine  what  can  be 
done  in  parallel  and  what  activities  need  to  wait  for  others  to  complete.  As  an  example,  Figure  10.10  shows  how 
the  activities  involved  in  producing  the  invitations  depend  on  one  another.  Showing  the  activities  in  rectangles 
and  their  relationships  as  arrows  is  called  a  precedence  diagramming  method  (PDM).  This  kind  of  diagram  is  also 
called  an  activity-on-node  (AON)  diagram. 

Another  way  to  show  how  tasks  relate  is  with  the  activity-on-arrow  (AO A)  diagram.  Although  AON  is  more  com¬ 
monly  used  and  is  supported  by  all  project  management  programs,  PERT  is  the  best-known  AOA-type  diagram 
and  is  the  historical  basis  of  all  network  diagramming.  The  main  difference  is  the  AOA  diagram  is  traditionally 
drawn  using  circles  as  the  nodes,  with  nodes  representing  the  beginning  and  ending  points  of  the  arrows  or  tasks. 
In  the  AOA  network,  the  arrows  represent  the  activities  or  tasks  (Figure  10.11). 
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Figure  10.10:  An  example  of  an  activity  on  node  (AON)  diagram. 
Illustration  from  Barron  &  Barron  Project  Management  for 
Scientists  and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


All  network  diagrams  have  the  advantages  of  showing  task  interdependencies,  start  and  end  times,  and  the  critical 
path  (the  longest  path  through  the  network)  but  the  AOA  network  diagram  has  some  disadvantages  that  limit  the 
use  of  the  method. 


Figure  10.11:  An  example  of  an  activity  arrow  (AOA)  network 
diagram. 

Illustration  from  Barron  &  Barron  Project  Management  for 
Scientists  and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


The  three  major  disadvantages  of  the  AOA  method  are: 

•  The  AOA  network  can  only  show  finish-to-start  relationships.  It  is  not  possible  to  show  lead  and  lag  except 
by  adding  or  subtracting  time,  which  makes  project  tracking  difficult. 

•  There  are  instances  when  dummy  activities  can  occur  in  an  AOA  network.  Dummy  activities  are  activities 
that  show  the  dependency  of  one  task  on  other  tasks  but  for  other  than  technical  reasons.  For  example, 
one  task  may  depend  on  another  because  it  would  be  more  cost  effective  to  use  the  same  resources  for  the 
two;  otherwise  the  two  tasks  could  be  accomplished  in  parallel.  Dummy  activities  do  not  have  durations 
associated  with  them.  They  simply  show  that  a  task  has  some  kind  of  dependence  on  another  task. 

•  AOA  diagrams  are  not  as  widely  used  as  AON  diagrams  simply  because  the  latter  are  somewhat  simpler  to 
use,  and  all  project  management  software  programs  can  accommodate  AON  networks,  whereas  not  all  can 
accommodate  AOA  networks. 


The  Critical  Path 

The  critical  path  describes  the  sequence  of  tasks  that  would  enable  the  project  to  be  completed  in  the  shortest 
possible  time.  It  is  based  on  the  idea  that  some  tasks  must  be  completed  before  others  can  begin.  A  critical  path 
diagram  is  a  useful  tool  for  scheduling  dependencies  and  controlling  a  project.  In  order  to  identify  the  critical  path, 
the  length  of  time  that  each  task  will  take  must  be  calculated. 

Let’s  take  a  look  at  an  example.  The  length  of  time  in  weeks  for  each  key  stage  is  estimated: 
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Key  stage 

Estimated  time  in  weeks 

A 

Secure  funds 

0 

B 

Negotiate  with  other  agen¬ 
cies 

4 

C 

Form  advisory  group 

4 

D 

Establish  data  collection 
plan 

6 

E 

Collect  data 

4 

F 

Write  directory  text 

4 

G 

Identify  printer 

2 

H 

Agree  print  contract 

2 

I 

Print  directory 

4 

J 

Agree  distribution  plan 

12 

K 

Organize  distribution 

4 

L 

Distribute  directory 

2 

Table  10.1  Stages  of  the  Critical  Path 

Source:  http://labspace.open.ac.uk/mod/resource/view.php?id=451674 

We  have  given  the  key  stage  “Secure  funds”  an  estimated  time  of  zero  weeks  because  the  project  cannot  start 
without  the  availability  of  some  funding,  although  estimates  would  provide  detail  at  a  later  stage.  The  stages  can 
now  be  lined  up  to  produce  a  network  diagram  that  shows  that  there  are  three  paths  from  start  to  finish  and  that 
the  lines  making  up  each  path  have  a  minimum  duration  (Figure  10.12). 

If  we  now  trace  each  of  the  possible  paths  to  “Distribute  directory”  (the  finishing  point),  taking  dependencies  into 
account,  the  route  that  has  the  longest  duration  is  known  as  the  critical  path.  This  is  the  minimum  time  in  which  it 
will  be  possible  to  complete  the  project. 


Figure  10.12:  Critical  Path  Diagram 


In  this  example,  the  critical  path  is  A-B-C-D-E-F-I-L,  and  the  earliest  completion  date  for  the  project  is  the  sum 
of  the  estimated  times  for  all  the  stages  on  the  critical  path  -  28  weeks  -  from  the  point  of  securing  the  funding. 
All  the  key  stages  on  the  critical  path  must  be  completed  on  time  if  the  project  is  to  be  finished  on  schedule. 

If  the  projected  total  time  is  much  longer  than  the  project  sponsor’s  expectations,  you  will  need  to  renegotiate  the 
time  scale.  Mapping  the  critical  path  helps  to  identify  the  activities  that  need  to  be  monitored  most  closely. 


90  •  PROJECT  MANAGEMENT 


Attribution 

This  chapter  of  Project  Management  is  a  derivative  copy  of  Project  Management  by  Merrie  Barron  and  Andrew 
Barron  licensed  under  Creative  Commons  Attribution  3.0  Unported,  Gantt  Chart  by  Wikipedia  licensed  under 
Creative  Commons  Attribution-Share  Alike  3.0  Unported  and  Planning  a  Project  by  OpenLearn  Labspace  under 
Creative  Commons  Attribution  3.0  Unported. 


11.  Resource  Planning 


ADRIENNE  WATT 


In  the  previous  wedding  case  study,  it  is  clear  that  Steve  and  Susan  have  resource  problems.  Getting  a  handle  on 
all  of  the  tasks  that  have  to  be  done  is  a  great  start,  but  it’s  not  enough  to  know  the  tasks  and  the  order  they  come 
in.  Before  you  can  put  the  final  schedule  together,  you  need  to  know  who  is  going  to  do  each  job,  and  the  things 
they  need  so  they  can  do  it. 

“We’ve  got  so  much  to  do!  Invitations,  catering,  music...  and  I’ve  got  no  idea  who’s  going  to  do  it  all.  I’m  totally 
overwhelmed.”  From  this  statement  it  is  clear  that  Susan  is  worried  about  human  resources.  In  comparison,  Steve 
realizes  that  not  all  resources  are  people:  “And  it’s  not  just  people.  We  need  food,  flowers,  a  cake,  a  sound  system, 
and  a  venue.  How  do  we  get  a  handle  on  this?” 

Resources  are  people,  equipment,  place,  money,  or  anything  else  that  you  need  in  order  to  do  all  of  the  activities 
that  you  planned  for.  Every  activity  in  your  activity  list  needs  to  have  resources  assigned  to  it.  Before  you  can 
assign  resources  to  your  project,  you  need  to  know  their  availability.  Resource  availability  includes  information 
about  what  resources  you  can  use  on  your  project,  when  they’re  available  to  you,  and  the  conditions  of  their  avail¬ 
ability.  Don’t  forget  that  some  resources,  like  consultants  or  training  rooms,  have  to  be  scheduled  in  advance,  and 
they  might  only  be  available  at  certain  times.  You’ll  need  to  know  this  before  you  can  finish  planning  your  pro¬ 
ject.  If  you  are  starting  to  plan  in  January,  a  June  wedding  is  harder  to  plan  than  one  in  December,  because  the 
wedding  halls  are  all  booked  up  in  advance.  That  is  clearly  a  resource  constraint.  You’ll  also  need  the  activity  list 
that  you  created  earlier,  and  you’ll  need  to  know  how  your  organization  typically  handles  resources.  Once  you’ve 
got  a  handle  on  these  things,  you’re  set  for  resource  estimation. 


Estimating  the  Resources 

The  goal  of  activity  resource  estimating  is  to  assign  resources  to  each  activity  in  the  activity  list.  There  are  five 
tools  and  techniques  for  estimating  activity  resources. 

Expert  judgment  means  bringing  in  experts  who  have  done  this  sort  of  work  before  and  getting  their  opinions  on 
what  resources  are  needed. 

Alternative  analysis  means  considering  several  different  options  for  how  you  assign  resources.  This  includes 
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varying  the  number  of  resources  as  well  as  the  kind  of  resources  you  use.  Many  times,  there’s  more  than  one  way 
to  accomplish  an  activity  and  alternative  analysis  helps  decide  among  the  possibilities. 

Published  estimating  data  is  something  that  project  managers  in  a  lot  of  industries  use  to  help  them  figure  out 
how  many  resources  they  need.  They  rely  on  articles,  books,  journals,  and  periodicals  that  collect,  analyze,  and 
publish  data  from  other  people’s  projects. 

Project  management  software  such  as  Microsoft  Project  will  often  have  features  designed  to  help  project  man¬ 
agers  estimate  resource  needs  and  constraints  and  find  the  best  combination  of  assignments  for  the  project. 

Bottom-up  estimating  means  breaking  down  complex  activities  into  pieces  and  working  out  the  resource  assign¬ 
ments  for  each  piece.  It  is  a  process  of  estimating  individual  activity  resource  need  or  cost  and  then  adding  these 
up  together  to  come  up  with  a  total  estimate.  Bottom-up  estimating  is  a  very  accurate  means  of  estimating,  pro¬ 
vided  the  estimates  at  the  schedule  activity  level  are  accurate.  However,  it  takes  a  considerable  amount  of  time 
to  perform  bottom-up  estimating  because  every  activity  must  be  assessed  and  estimated  accurately  to  be  included 
in  the  bottom-up  calculation.  The  smaller  and  more  detailed  the  activity,  the  greater  the  accuracy  and  cost  of  this 
technique. 


Estimating  Activity  Durations 

Once  you’re  done  with  activity  resource  estimating,  you’ve  got  everything  you  need  to  figure  out  how  long  each 
activity  will  take.  That’s  done  in  a  process  called  activity  duration  estimating.  This  is  where  you  look  at  each 
activity  in  the  activity  list,  consider  its  scope  and  resources,  and  estimate  how  long  it  will  take  to  perform. 

Estimating  the  duration  of  an  activity  means  starting  with  the  information  you  have  about  that  activity  and  the 
resources  that  are  assigned  to  it,  and  then  working  with  the  project  team  to  come  up  with  an  estimate.  Most  of  the 
time  you’ll  start  with  a  rough  estimate  and  then  refine  it  to  make  it  more  accurate.  You’ll  use  these  five  tools  and 
techniques  to  create  the  most  accurate  estimates: 

Expert  judgment  will  come  from  your  project  team  members  who  are  familiar  with  the  work  that  has  to  be  done. 
If  you  don’t  get  their  opinion,  there’s  a  huge  risk  that  your  estimates  will  be  wrong. 

Analogous  estimating  is  when  you  look  at  similar  activities  from  previous  projects  and  how  long  they  took.  This 
only  works  if  the  activities  and  resources  are  similar. 

Parametric  estimating  means  plugging  data  about  your  project  into  a  formula,  spreadsheet,  database,  or  computer 
program  that  comes  up  with  an  estimate.  The  software  or  formula  that  you  use  for  parametric  estimating  is  based 
on  a  database  of  actual  durations  from  past  projects. 

Three-point  estimating  is  when  you  come  up  with  three  numbers:  a  realistic  estimate  that’s  most  likely  to  occur,  an 
optimistic  one  that  represents  the  best-case  scenario,  and  a  pessimistic  one  that  represents  the  worst-case  scenario. 
The  final  estimate  is  the  weighted  average  of  the  three. 

Reserve  analysis  means  adding  extra  time  to  the  schedule  (called  a  contingency  reserve  or  a  buffer )  to  account  for 
extra  risk. 
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In  each  of  the  following  scenarios  of  planning  Steve  and  Susan’s  wedding,  determine  which  of  the  five  activity 
resource  estimation  tools  and  techniques  is  being  used.  (Solutions  follow.) 


Exercises 


Exercise  11.1  Sally  has  to  figure  out  what  to  do  for  the  music  at  Steve  and  Susan’s  wedding.  She  considers 
using  a  DJ,  a  rock  band,  or  a  string  quartet. 

Exercise  11.2  The  latest  issue  of  Wedding  Planner’s  Journal  has  an  article  on  working  with  caterers.  It 
includes  a  table  that  shows  how  many  waiters  work  with  various  guest-list  sizes. 

Exercise  11.3  There’s  a  national  wedding  consultant  who  specializes  in  Caribbean-themed  weddings.  Sally 
gets  in  touch  with  her  to  ask  about  menu  options. 

Exercise  11.4  Sally  downloads  and  fills  out  a  specialized  spreadsheet  that  a  project  manager  developed  to 
help  with  wedding  planning. 

Exercise  11.5  There’s  so  much  work  that  has  to  be  done  to  set  up  the  reception  hall  that  Sally  has  to  break 
it  down  into  five  different  activities  in  order  to  assign  jobs. 

Exercise  11.6  Sally  asks  Steve  and  Susan  to  visit  several  different  caterers  and  sample  various  potential 
items  for  the  menu. 

Exercise  11.7  Sally  calls  up  her  friend  who  knows  specifics  of  the  various  venues  in  their  area  for  advice 
on  which  one  would  work  best. 

Exercise  11.8  There  are  two  different  catering  companies  at  the  wedding.  Sally  asks  the  head  chef  at  each 
of  them  to  give  her  an  estimate  of  how  long  it  will  take  each  of  them  to  do  the  job. 

Exercise  11.9  There’s  a  spreadsheet  Sally  always  uses  to  figure  out  how  long  it  takes  guest  to  RSVP.  She 
enters  the  number  of  guests  and  their  zip  codes,  and  it  calculates  estimates  for  her. 

Exercise  11.10  Sally’s  done  four  weddings  that  are  very  similar  to  Steve  and  Susan’s,  and  in  all  four  of 
them,  it  took  exactly  the  same  amount  of  time  for  the  caterers  to  set  up  the  reception  hall. 

Solutions 

Solution  to  Exercise  11.1 
Alternative  analysis 

Solution  to  Exercise  11.2 
Published  estimating  data 

Solution  to  Exercise  11.3 
Expert  judgment 

Solution  to  Exercise  11.4 
Project  management  software 

Solution  to  Exercise  11.5 
Bottom-up  estimating 

Solution  to  Exercise  11.6 
Alternative  analysis 

Solution  to  Exercise  11.7 
Expert  judgment 
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Solution  to  Exercise  11.8 
Expert  judgment 

Solution  to  Exercise  11.9 
Parametric  estimating 

Solution  to  Exercise  11.10 
Analogous  estimating 


The  activity  duration  estimates  are  an  estimate  of  how  long  each  activity  in  the  activity  list  will  take.  This  is  a 
quantitative  measure  usually  expressed  in  hours,  weeks,  days,  or  months.  Any  work  period  is  fine,  and  you’ll  use 
different  work  periods  for  different  jobs.  A  small  job  (like  booking  a  Dl)  may  take  just  a  few  hours;  a  bigger  job 
(like  catering,  including  deciding  on  a  menu,  ordering  ingredients,  cooking  food,  and  serving  guests  on  the  big 
day)  could  take  days. 

Another  thing  to  keep  in  mind  when  estimating  the  duration  of  activities  is  determining  the  effort  involved.  Dura¬ 
tion  is  the  amount  of  the  time  that  an  activity  takes,  while  effort  is  the  total  number  of  person-hours  that  are 
expended.  If  it  takes  two  people  six  hours  to  carve  the  ice  sculpture  for  the  centerpiece  of  a  wedding,  the  duration 
is  six  hours.  But  if  two  people  worked  on  it  for  the  whole  time,  it  took  12  person-hours  of  effort  to  create. 

You’ll  also  learn  more  about  the  specific  activities  while  you’re  estimating  them.  That’s  something  that  always 
happens.  You  have  to  really  think  through  all  of  the  aspects  of  a  task  in  order  to  estimate  it.  As  you  learn  more 
about  the  specific  activities  remember  to  update  the  activity  attributes. 

If  we  go  back  to  our  case  study  of  the  wedding,  we  can  see  that  while  Sally  has  a  handle  on  how  long  things  are 
going  to  take,  she  still  has  some  work  to  do  before  she  has  the  whole  project  under  control.  Steve  and  Susan  know 
where  they  want  to  get  married,  and  they  have  the  place  booked  now.  But,  what  about  the  caterer?  They  have  no 
idea  who’s  going  to  be  providing  food.  And  what  about  the  band  they  want?  Will  the  timing  with  their  schedule 
work  out?  “If  the  caterers  come  too  early,  the  food  will  sit  around  under  heat  lamps.  But  if  they  come  too  late,  the 
band  won’t  have  time  to  play.  I  just  don’t  see  how  we’ll  ever  work  this  out.” 

It’s  not  easy  to  plan  for  a  lot  of  resources  when  they  have  tight  time  restrictions  and  overlapping  constraints.  How 
do  you  figure  out  a  schedule  that  makes  everything  fit  together?  You’re  never  going  to  have  the  complete  resource 
picture  until  you  have  finished  building  the  schedule.  And  the  same  goes  for  your  activity  list  and  duration  esti¬ 
mates!  It’s  only  when  you  lay  out  the  schedule  that  you’ll  figure  out  that  some  of  your  activities  and  durations 
didn’t  quite  work. 


Project  Schedule  and  Critical  Path 

The  project  schedule  should  be  approved  and  signed  off  by  stakeholders  and  functional  managers.  This  ensures 
they  have  read  the  schedule,  understand  the  dates  and  resource  commitments,  and  will  cooperate.  You’ll  also  need 
to  obtain  confirmation  that  resources  will  be  available  as  outlined  in  the  schedule.  The  schedule  cannot  be  final¬ 
ized  until  you  receive  approval  and  commitment  for  the  resource  assignments  outlined  in  it.  Once  the  schedule  is 
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approved,  it  will  become  your  baseline  for  the  remainder  of  the  project.  Project  progress  and  task  completion  will 
be  monitored  and  tracked  against  the  project  schedule  to  determine  if  the  project  is  on  course  as  planned. 

The  schedule  can  be  displayed  in  a  variety  of  ways,  some  of  which  are  variations  of  what  you  have  already  seen. 
Project  schedule  network  diagrams  will  work  as  schedule  diagrams  when  you  add  the  start  and  finish  dates  to  each 
activity.  These  diagrams  usually  show  the  activity  dependencies  and  critical  path. 

The  critical  path  method  is  an  important  tool  for  keeping  your  projects  on  track.  Every  network  diagram  has  some¬ 
thing  that  is  called  the  critical  path.  It’s  the  string  of  activities  that,  if  you  add  up  all  of  the  durations,  is  longer  than 
any  other  path  through  the  network.  It  usually  starts  with  the  first  activity  in  the  network  and  usually  ends  with 
the  last  one. 

Steve 

Aunt  Jane  is  a  vegetarian.  That  won’t  be  a  problem,  right? 

Susan 

Well,  let’s  see.  What  menu  did  we  give  the  caterers? 

Steve 

We  didn’t  give  it  to  them  yet;  because  we  won’t  have  the  final  menu  until  everyone  RSVPs  and  lets  we  know 
which  entree  they  want. 

Susan 

But  they  can’t  RSVP  because  we  haven’t  sent  out  the  invitations!  What’s  holding  that  up? 

Steve 

We’re  still  waiting  to  get  them  back  from  the  printer.  We  can’t  send  them  out  if  we  don’t  have  them  yet! 

Susan 

Oh  no!  I  still  have  to  tell  the  printer  what  to  print  on  the  invitations  and  what  paper  to  use. 

Steve 

But  you  were  waiting  on  that  until  we  finished  the  guest  list. 

Susan 

What  a  mess! 

Steve  thought  Aunt  Jane  being  a  vegetarian  was  just  a  little  problem.  But  it  turns  out  to  be  a  lot  bigger  than  either 
Steve  or  Susan  realized  at  first.  How  did  a  question  about  one  guest’s  meal  lead  to  such  a  huge  mess? 

The  reason  that  the  critical  path  is  critical  is  that  every  single  activity  on  the  path  must  finish  on  time  in  order  for 
the  project  to  come  in  on  time.  A  delay  in  any  one  of  the  critical  path  activities  will  cause  the  entire  project  to  be 
delayed  (Figure  11.1). 
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Figure  11.1:  An  example  of  problems  that  can  be  caused  within 
the  critical  path. 

Illustration  from  Barron  &  Barron  Project  Management  for 
Scientists  and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


Knowing  where  your  critical  path  is  can  give  you  a  lot  of  freedom.  If  you  know  an  activity  is  not  on  the  critical 
path,  then  you  know  a  delay  in  that  activity  may  not  necessarily  delay  the  project.  This  can  really  help  you  handle 
emergency  situations.  Even  better,  it  means  that  if  you  need  to  bring  your  project  in  earlier  than  was  originally 
planned,  you  know  that  adding  resources  to  the  critical  path  will  be  much  more  effective  than  adding  them  else¬ 
where. 

It’s  easy  to  find  the  critical  path  in  any  project.  Of  course,  on  a  large  project  with  dozens  or  hundreds  of  tasks, 
you’ll  probably  use  software  like  Microsoft  Project  to  find  the  critical  path  for  you.  But  when  it  does,  it’s  follow¬ 
ing  the  same  exact  steps  that  are  followed  here  (Figure  11.12). 


Step  1.  Start  with  a  network  diagram. 


Figure  11.2  Step  1  Network  Diagram 

Illustration  from  Barron  &  Barron  Project  Management  for 

Scientists  and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


Step  2,  Find  all  the  paths  in  the  diagram.  A  path  is  any  string  of  activities  that  goes  from  the  start  of  the  project  to 
the  end. 

Sum  Activity  "A"  Activity  *'B"  ->  t-ini«h 
Stan  Activity  "A"  ->  Activity  **C~  ^  finish 
Start  Activity  “D"  4  Activity  "E"  4  llnith 


Step  3.  Find  the  duration  of  each  path  by  adding  up  the  durations  of  each  of  the  activities  on  the  path. 

Stan  A  Activity  “A"  ->  Activity  "B"  A  Finish  =  4  +  7  =  II 
Stan  ->  Activity  “A"  A  Activity  “C"  A  Finish  =  4  +  2  =  6 
Start  A  Activity  “D”  ->  Activity  “E”  ->  Finish  =  3  +  5  =  8 
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Step  4.  The  first  path  has  a  duration  of  11,  which  is  longer  than  the  other  paths,  so  it’s  the  critical  path. 
The  schedule  can  also  be  displayed  using  a  Gantt  chart  (Figure  11.3). 


Figure  11.3:  An  example  of  a  Gantt  chart. 

Illustration  from  Barron  &  Barron  Project  Management  for 
Scientists  and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


Resource  Management 

Resource  management  is  the  efficient  and  effective  deployment  of  an  organization’s  resources  when  they  are 
needed.  Such  resources  may  include  financial  resources,  inventory,  human  skills,  production  resources,  or  infor¬ 
mation  technology  (IT).  In  the  realm  of  project  management,  processes,  techniques,  and  philosophies  for  the  best 
approach  for  allocating  resources  have  been  developed.  These  include  discussions  on  functional  versus  cross¬ 
functional  resource  allocation  as  well  as  processes  espoused  by  organizations  like  the  Project  Management  Insti¬ 
tute  (PM1)  through  the  methodology  of  project  management  outlined  in  their  publication  A  Guide  to  the  Project 
Management  Body  of  Knowledge  (PMBOK).  Resource  management  is  a  key  element  to  activity  resource  estimat¬ 
ing  and  project  human  resource  management.  As  is  the  case  with  the  larger  discipline  of  project  management, 
there  are  resource  management  software  tools  available  that  automate  and  assist  the  process  of  resource  allocation 
to  projects. 


HR  Planning 

The  most  important  resource  to  a  project  is  its  people — the  project  team.  Projects  require  specific  expertise  at  spe¬ 
cific  moments  in  the  schedule,  depending  on  the  milestones  being  delivered  or  the  given  phase  of  the  project.  An 
organization  can  host  several  strategic  projects  concurrently  over  the  course  of  a  budget  year,  which  means  that 
its  employees  can  be  working  on  more  than  one  project  at  a  time.  Alternatively,  an  employee  may  be  seconded 
away  from  his  or  her  role  within  an  organization  to  become  part  of  a  project  team  because  of  a  particular  exper¬ 
tise.  Moreover,  projects  often  require  talent  and  resources  that  can  only  be  acquired  via  contract  work  and  third 
party  vendors.  Procuring  and  coordinating  these  human  resources,  in  tandem  with  managing  the  time  aspect  of  the 
project,  is  critical  to  overall  success. 

Managing  the  Team 

In  order  to  successfully  meet  the  needs  of  a  project,  it  is  important  to  have  a  high-performing  project  team  made 
up  of  individuals  who  are  both  technically  skilled  and  motivated  to  contribute  to  the  project’s  outcome.  One  of  the 
many  responsibilities  of  a  project  manager  is  to  enhance  the  ability  of  each  project  team  member  to  contribute  to 
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the  project,  while  also  fostering  individual  growth  and  accomplishment.  At  the  same  time,  each  individual  must 
be  encouraged  to  share  ideas  and  work  with  others  toward  a  common  goal. 

Through  performance  evaluation,  the  manager  will  get  the  information  needed  to  ensure  that  the  team  has  ade¬ 
quate  knowledge,  to  establish  a  positive  team  environment  and  a  healthy  communication  climate,  to  work  prop¬ 
erly,  and  to  ensure  accountability. 

Managing  the  project  team  includes  appraisal  of  employee  performance  and  project  performance.  The  perfor¬ 
mance  reports  provide  the  basis  for  managerial  decisions  on  how  to  manage  the  project  team. 

Employee  performance  includes  the  employee’s  work  results  such  as: 

•  Quality  and  quantity  of  outputs 

•  Work  behavior  (such  as  punctuality) 

•  Job-related  attributes  (such  as  cooperation  and  initiative) 

After  conducting  employee  performance  reviews,  project  managers  should: 

•  Provide  feedback  to  employees  about  how  well  they  have  performed  on  established  goals 

•  Provide  feedback  to  employees  about  areas  in  which  they  are  weak  or  could  do  better 

•  Take  corrective  action  to  address  problems  with  employees  performing  at  or  below  minimum  expectations 

•  Reward  superior  performers  to  encourage  their  continued  excellence 

Techniques  for  Managing  Resources 

One  resource  management  technique  is  resource  leveling.  It  aims  at  smoothing  the  stock  of  resources  on  hand, 
reducing  both  excess  inventories  and  shortages. 

The  required  data  are  the  demands  for  various  resources,  forecast  by  time  period  into  the  future  as  far  as  is  rea¬ 
sonable;  the  resources’  configurations  required  in  those  demands;  and  the  supply  of  the  resources,  again  forecast 
by  time  period  into  the  future  as  far  as  is  reasonable. 

The  goal  is  to  achieve  100%  utilization.  However  that  is  very  unlikely,  when  weighted  by  important  metrics  and 
subject  to  constraints;  for  example:  meeting  a  minimum  quality  level,  but  otherwise  minimizing  cost. 

Resource  Leveling 

Resource  leveling  is  used  to  examine  unbalanced  use  of  resources  (usually  people  or  equipment)  over  time  and 
for  resolving  over-allocations  or  conflicts. 

When  performing  project  planning  activities,  the  manager  will  attempt  to  schedule  certain  tasks  simultaneously. 
When  more  resources  such  as  machines  or  people  are  needed  than  are  available,  or  perhaps  a  specific  person  is 
needed  in  both  tasks,  the  tasks  will  have  to  be  rescheduled  sequentially  to  manage  the  constraint.  Resource  level¬ 
ing  during  project  planning  is  the  process  of  resolving  these  conflicts.  It  can  also  be  used  to  balance  the  workload 
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of  primary  resources  over  the  course  of  the  project,  usually  at  the  expense  of  one  of  the  traditional  triple  con¬ 
straints  (time,  cost,  scope). 

When  using  specially  designed  project  software,  leveling  typically  means  resolving  conflicts  or  over-allocations  in 
the  project  plan  by  allowing  the  software  to  calculate  delays  and  update  tasks  automatically.  Project  management 
software  leveling  requires  delaying  tasks  until  resources  are  available.  In  more  complex  environments,  resources 
could  be  allocated  across  multiple,  concurrent  projects  thus  requiring  the  process  of  resource  leveling  to  be  per¬ 
formed  at  company  level. 

In  either  definition,  leveling  could  result  in  a  later  project  finish  date  if  the  tasks  affected  are  in  the  critical  path. 


Working  with  Individuals 

Working  with  other  people  involves  dealing  with  them  both  logically  and  emotionally.  A  successful  working  rela¬ 
tionship  between  individuals  begins  with  appreciating  the  importance  of  emotions  and  how  they  relate  to  person¬ 
ality  types,  leadership  styles,  negotiations,  and  setting  goals. 

Emotional  Intelligence 

Emotions  are  both  a  mental  and  physiological  response  to  environmental  and  internal  stimuli.  Leaders  need  to 
understand  and  value  their  emotions  to  appropriately  respond  to  the  client,  project  team,  and  project  environment. 

Emotional  intelligence  includes  the  following: 

•  Self-awareness 

•  Self-regulation 

•  Empathy 

•  Relationship  management 

Emotions  are  important  to  generating  energy  around  a  concept,  building  commitment  to  goals,  and  developing 
high-performing  teams.  Emotional  intelligence  is  an  important  part  of  the  project  manager’s  ability  to  build  trust 
among  the  team  members  and  with  the  client.  It  is  an  important  factor  in  establishing  credibility  and  an  open  dia¬ 
logue  with  project  stakeholders.  Emotional  intelligence  is  critical  for  project  managers,  and  the  more  complex  the 
project  profile,  the  more  important  the  project  manager’s  emotional  intelligence  becomes  to  project  success. 

Personality  Types 

Personality  types  refer  to  the  differences  among  people  in  such  matters  as  what  motivates  them,  how  they  process 
information,  how  they  handle  conflict,  etc.  Understanding  people’s  personality  types  is  acknowledged  as  an  asset 
in  interacting  and  communicating  with  them  more  effectively.  Understanding  your  personality  type  as  a  project 
manager  will  assist  you  in  evaluating  your  tendencies  and  strengths  in  different  situations.  Understanding  others’ 
personality  types  can  also  help  you  coordinate  the  skills  of  your  individual  team  members  and  address  the  various 
needs  of  your  client. 

The  Myers-Briggs  Type  Indicator  (MBTI)  is  one  of  most  widely  used  tools  for  exploring  personal  preference,  with 
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more  than  two  million  people  taking  the  MBTI  each  year.  The  MBTI  is  often  referred  to  as  simply  the  Myers- 
Briggs.  It  is  a  tool  that  can  be  used  in  project  management  training  to  develop  awareness  of  preferences  for  pro¬ 
cessing  information  and  relationships  with  other  people. 

Based  on  the  theories  of  psychologist  Carl  Jung,  the  Myers-Briggs  uses  a  questionnaire  to  gather  information  on 
the  ways  individuals  prefer  to  use  their  perception  and  judgment.  Perception  represents  the  way  people  become 
aware  of  people  and  their  environment.  Judgment  represents  the  evaluation  of  what  is  perceived.  People  per¬ 
ceive  things  differently  and  reach  different  conclusions  based  on  the  same  environmental  input.  Understanding 
and  accounting  for  these  differences  is  critical  to  successful  project  leadership. 

The  Myers-Briggs  identifies  16  personality  types  based  on  four  preferences  derived  from  the  questionnaire.  The 
preferences  are  between  pairs  of  opposite  characteristics  and  include  the  following: 

Extroversion  (E)-Introversion  (I) 

Sensing  (S)-Intuition  (N) 

Thinking  (T)-Feeling  (F) 

Judging  (J) -Perceiving  (P) 

Sixteen  Myers-Briggs  types  can  be  derived  from  the  four  dichotomies.  Each  of  the  16  types  describes  a  prefer¬ 
ence:  for  focusing  on  the  inner  or  outer  world  (E-I),  for  approaching  and  internalizing  information  (S-I),  for  mak¬ 
ing  decisions  (T-F),  and  for  planning  (J-P).  For  example,  an  ISTJ  is  a  Myers-Briggs  type  who  prefers  to  focus  on 
the  inner  world  and  basic  information,  prefers  logic,  and  likes  to  decide  quickly. 

It  is  important  to  note  that  there  is  no  best  type  and  that  effective  interpretation  of  the  Myers-Briggs  requires 
training.  The  purpose  of  the  Myers-Briggs  is  to  understand  and  appreciate  the  differences  among  people.  This 
understanding  can  be  helpful  in  building  the  project  team,  developing  common  goals,  and  communicating  with 
project  stakeholders.  For  example,  different  people  process  information  differently.  Extroverts  prefer  face-to-face 
meetings  as  the  primary  means  of  communicating,  while  introverts  prefer  written  communication.  Sensing  types 
focus  on  facts,  and  intuitive  types  want  the  big  picture. 

On  larger,  more  complex  projects,  some  project  managers  will  use  the  Myers-Briggs  as  a  team-building  tool  dur¬ 
ing  project  start-up.  This  is  typically  a  facilitated  work  session  where  team  members  take  the  Myers-Briggs  and 
share  with  the  team  how  they  process  information,  what  communication  approaches  they  prefer,  and  what  deci¬ 
sion-making  preferences  they  have.  This  allows  the  team  to  identify  potential  areas  of  conflict,  develop  commu¬ 
nication  strategies,  and  build  an  appreciation  for  the  diversity  of  the  team. 

Another  theory  of  personality  typing  is  the  DISC  method,  which  rates  people’s  personalities  by  testing  a  person’s 
preferences  in  word  associations  in  the  following  four  areas: 

Dominance/Drive — relates  to  control,  power,  and  assertiveness 
Inducement/Influence — relates  to  social  situations  and  communication 
Submission/Steadiness — relates  to  patience,  persistence,  and  thoughtfulness 
Compliance/Conscientiousness — relates  to  structure  and  organization 

Understanding  the  differences  among  people  is  a  critical  leadership  skill.  This  includes  understanding  how  people 
process  information,  how  different  experiences  influence  the  way  people  perceive  the  environment,  and  how  peo- 
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pie  develop  filters  that  allow  certain  information  to  be  incorporated  while  other  information  is  excluded.  The 
more  complex  the  project,  the  more  important  the  understanding  of  how  people  process  information,  make  deci¬ 
sions,  and  deal  with  conflict.  There  are  many  personality-type  tests  that  have  been  developed  and  explore  different 
aspects  of  people’s  personalities.  It  might  be  prudent  to  explore  the  different  tests  available  and  utilize  those  that 
are  most  beneficial  for  your  team. 

Leadership  Styles 

Leadership  style  is  a  function  of  both  the  personal  characteristics  of  the  leader  and  the  environment  in  which  the 
leadership  must  occur,  and  a  topic  that  several  researchers  have  attempted  to  understand.  Robert  Tannenbaum  and 
Warren  Schmidt  described  leaders  as  either  autocratic  or  democratic  (1958).  Harold  Leavitt  described  leaders  as 
pathfinders  (visionaries),  problem  solvers  (analytical),  or  implementers  (team  oriented)  (1986).  James  MacGregor 
Burns  conceived  leaders  as  either  transactional  (focused  on  actions  and  decisions)  or  transformational  (focused  on 
the  long-term  needs  of  the  group  and  organization)  (1978). 

Fred  Fiedler  introduced  his  contingency  theory,  which  is  the  ability  of  leaders  to  adapt  their  leadership  approach 
to  the  environment  (1971).  Most  leaders  have  a  dominant  leadership  style  that  is  most  comfortable  for  them. 
For  example,  most  engineers  spend  years  training  in  analytical  problem  solving  and  often  develop  an  analytical 
approach  to  leadership. 

A  leadership  style  reflects  personal  characteristics  and  life  experiences.  Although  a  project  manager’s  leadership 
style  may  be  predominantly  a  pathfinder  (using  Leavitt’s  taxonomy),  most  project  managers  become  problem 
solvers  or  implementers  when  they  perceive  the  need  for  these  leadership  approaches.  The  leadership  approach 
incorporates  the  dominant  leadership  style  and  Fiedler’s  contingency  focus  on  adapting  to  the  project  environ¬ 
ment. 

No  particular  leadership  approach  is  specifically  appropriate  for  managing  a  project.  Due  to  the  unique  circum¬ 
stances  inherent  in  each  project,  the  leadership  approach  and  the  management  skills  required  to  be  successful  vary 
depending  on  the  complexity  profile  of  the  project.  However,  the  Project  Management  Institute  published  Shi  and 
Chen’s  research  that  studied  project  management  leadership  traits  and  concluded  that  good  communication  skills 
and  the  ability  to  build  harmonious  relationships  and  motivate  others  are  essential  (2006).  Beyond  this  broad  set 
of  leadership  skills,  the  successful  leadership  approach  will  depend  on  the  profile  of  the  project.  For  example,  a 
transactional  project  manager  with  a  strong  command-and-control  leadership  approach  may  be  very  successful  on 
a  small  software  development  project  or  a  construction  project,  where  tasks  are  clear,  roles  are  well  understood, 
and  the  project  environment  is  cohesive.  This  same  project  manager  is  less  likely  to  be  successful  on  a  larger, 
more  complex  project  with  a  diverse  project  team  and  complicated  work  processes. 

Matching  the  appropriate  leadership  style  and  approach  to  the  complexity  profile  of  the  project  is  a  critical  element 
of  project  success.  Even  experienced  project  managers  are  less  likely  to  be  successful  if  their  leadership  approach 
does  not  match  the  complexity  profile  of  the  project. 

Each  project  phase  may  also  require  a  different  leadership  approach.  During  the  start-up  phase  of  a  project,  when 
new  team  members  are  first  assigned  to  the  project,  the  project  may  require  a  command-and-control  leadership 
approach.  Later,  as  the  project  moves  into  the  conceptual  phase,  creativity  becomes  important,  and  the  project 
management  takes  on  a  more  transformational  leadership  approach.  Most  experienced  project  managers  are  able 
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to  adjust  their  leadership  approach  to  the  needs  of  the  project  phase.  Occasionally,  on  very  large  and  complex  pro¬ 
jects,  some  companies  will  bring  in  different  project  managers  for  various  phases  of  a  project.  Changing  project 
managers  may  bring  the  right  level  of  experience  and  the  appropriate  leadership  approach,  but  is  also  disruptive 
to  a  project.  Senior  management  must  balance  the  benefit  of  matching  the  right  leadership  approach  with  the  cost 
of  disrupting  established  relationships. 

Example:  Multinational  Textbook  Publishing  Project 

On  a  project  to  publish  a  new  textbook  at  a  major  publisher,  a  project  manager  led  a  team  that  included  members 
from  partners  that  were  included  in  a  joint  venture.  The  editorial  manager  was  Greek,  the  business  manager  was 
German,  and  other  members  of  the  team  were  from  various  locations  in  the  United  States  and  Europe.  In  addition 
to  the  traditional  potential  for  conflict  that  arises  from  team  members  from  different  cultures,  the  editorial  man¬ 
ager  and  business  manager  were  responsible  for  protecting  the  interest  of  their  company  in  the  joint  venture. 

The  project  manager  held  two  alignment  or  team-building  meetings.  The  first  was  a  two-day  meeting  held  at  a 
local  resort  and  included  only  the  members  of  the  project  leadership  team.  An  outside  facilitator  was  hired  to 
facilitate  discussion,  and  the  topic  of  cultural  conflict  and  organizational  goal  conflict  quickly  emerged.  The  team 
discussed  several  methods  for  developing  understanding  and  addressing  conflicts  that  would  increase  the  likeli¬ 
hood  of  finding  mutual  agreement. 

The  second  team-building  session  was  a  one-day  meeting  that  included  the  executive  sponsors  from  the  various 
partners  in  the  joint  venture.  With  the  project  team  aligned,  the  project  manager  was  able  to  develop  support  for 
the  publication  project’s  strategy  and  commitment  from  the  executives  of  the  joint  venture.  In  addition  to  build¬ 
ing  processes  that  would  enable  the  team  to  address  difficult  cultural  differences,  the  project  manager  focused  on 
building  trust  with  each  of  the  team  members.  The  project  manager  knew  that  building  trust  with  the  team  was  as 
critical  to  the  success  of  the  project  as  the  technical  project  management  skills  and  devoted  significant  manage¬ 
ment  time  to  building  and  maintaining  this  trust. 

Leadership  Skills 

The  project  manager  must  be  perceived  to  be  credible  by  the  project  team  and  key  stakeholders.  A  successful  pro¬ 
ject  manager  can  solve  problems  and  has  a  high  degree  of  tolerance  for  ambiguity.  On  projects,  the  environment 
changes  frequently,  and  the  project  manager  must  apply  the  appropriate  leadership  approach  for  each  situation. 

The  successful  project  manager  must  have  good  communication  skills.  All  project  problems  are  connected  to 
skills  needed  by  the  project  manager: 

•  Breakdown  in  communication  represents  the  lack  of  communication  skills 

•  Uncommitted  team  members  represents  the  lack  of  team-building  skills 

•  Role  confusion  represents  the  lack  of  organizational  skill 

Project  managers  need  a  large  numbers  of  skills.  These  skills  include  administrative  skills,  organizational  skills, 
and  technical  skills  associated  with  the  technology  of  the  project.  The  types  of  skills  and  the  depth  of  the  skills 
needed  are  closely  connected  to  the  complexity  profile  of  the  project.  Typically  on  smaller,  less  complex  projects, 
project  managers  need  a  greater  degree  of  technical  skill.  On  larger,  more  complex  projects,  project  managers 
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need  more  organizational  skills  to  deal  with  the  complexity.  On  smaller  projects,  the  project  manager  is  intimately 
involved  in  developing  the  project  schedule,  cost  estimates,  and  quality  standards.  On  larger  projects,  functional 
managers  are  typically  responsible  for  managing  these  aspects  of  the  project,  and  the  project  manager  provides 
the  organizational  framework  for  the  work  to  be  successful. 

Listening 

One  of  the  most  important  communication  skills  of  the  project  manager  is  the  ability  to  actively  listen.  Active 
listening  is  placing  oneself  in  the  speaker’s  position  as  much  as  possible,  understanding  the  communication  from 
the  point  of  view  of  the  speaker,  listening  to  the  body  language  and  other  environmental  cues,  and  striving  not 
just  to  hear,  but  to  understand.  Active  listening  takes  focus  and  practice  to  become  effective.  It  enables  a  project 
manager  to  go  beyond  the  basic  information  that  is  being  shared  and  to  develop  a  more  complete  understanding 
of  the  information. 

Example:  Client's  Body  Language 

A  client  just  returned  from  a  trip  to  Australia  where  he  reviewed  the  progress  of  the  project  with  his  company’s 
board  of  directors.  The  project  manager  listened  and  took  notes  on  the  five  concerns  expressed  by  the  board  of 
directors  to  the  client. 

The  project  manager  observed  that  the  client’s  body  language  showed  more  tension  than  usual.  This  was  a  cue  to 
listen  very  carefully.  The  project  manager  nodded  occasionally  and  clearly  demonstrated  he  was  listening  through 
his  posture,  small  agreeable  sounds,  and  body  language.  The  project  manager  then  began  to  provide  feedback  on 
what  was  said  using  phrases  like  “What  I  hear  you  say  is. . .”  or  “It  sounds  like.. . .”  The  project  manager  was  clar¬ 
ifying  the  message  that  was  communicated  by  the  client. 

The  project  manager  then  asked  more  probing  questions  and  reflected  on  what  was  said.  “It  sounds  as  if  it  was 
a  very  tough  board  meeting.”  “Is  there  something  going  on  beyond  the  events  of  the  project?”  From  these  obser¬ 
vations  and  questions,  the  project  manager  discovered  that  the  board  of  directors  meeting  did  not  go  well.  The 
company  had  experienced  losses  on  other  projects,  and  budget  cuts  meant  fewer  resources  for  the  project  and  an 
expectation  that  the  project  would  finish  earlier  than  planned.  The  project  manager  also  discovered  that  the  client’s 
future  with  the  company  would  depend  on  the  success  of  the  project.  The  project  manager  asked,  “Do  you  think 
we  will  need  to  do  things  differently?”  They  began  to  develop  a  plan  to  address  the  board  of  directors’  concerns. 

Through  active  listening,  the  project  manager  was  able  to  develop  an  understanding  of  the  issues  that  emerged 
from  the  board  meeting  and  participate  in  developing  solutions.  Active  listening  and  the  trusting  environment 
established  by  the  project  manager  enabled  the  client  to  safely  share  information  he  had  not  planned  on  sharing 
and  to  participate  in  creating  a  workable  plan  that  resulted  in  a  successful  project. 

In  the  example  above,  the  project  manager  used  the  following  techniques: 

•  Listening  intently  to  the  words  of  the  client  and  observing  the  client’s  body  language 

•  Nodding  and  expressing  interest  in  the  client  without  forming  rebuttals 

•  Providing  feedback  and  asking  for  clarity  while  repeating  a  summary  of  the  information  back  to  the  client 

•  Expressing  understanding  and  empathy  for  the  client 
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Active  listening  was  important  in  establishing  a  common  understanding  from  which  an  effective  project  plan 
could  be  developed. 

Negotiation 

When  multiple  people  are  involved  in  an  endeavor,  differences  in  opinions  and  desired  outcomes  naturally  occur. 
Negotiation  is  a  process  for  developing  a  mutually  acceptable  outcome  when  the  desired  outcome  for  each  party 
conflicts.  A  project  manager  will  often  negotiate  with  a  client,  team  members,  vendors,  and  other  project  stake¬ 
holders.  Negotiation  is  an  important  skill  in  developing  support  for  the  project  and  preventing  frustration  among 
all  parties  involved,  which  could  delay  or  cause  project  failure. 

Negotiations  involve  four  principles: 

1.  Separate  people  from  the  problem.  Framing  the  discussions  in  terms  of  desired  outcomes  enables  the 
negotiations  to  focus  on  finding  new  outcomes. 

2.  Focus  on  common  interests.  By  avoiding  the  focus  on  differences,  both  parties  are  more  open  to  finding 
solutions  that  are  acceptable. 

3.  Generate  options  that  advance  shared  interests.  Once  the  common  interests  are  understood,  solutions  that 
do  not  match  with  either  party’s  interests  can  be  discarded,  and  solutions  that  may  serve  both  parties’  inter¬ 
ests  can  be  more  deeply  explored. 

4.  Develop  results  based  on  standard  criteria.  The  standard  criterion  is  the  success  of  the  project.  This 
implies  that  the  parties  develop  a  common  definition  of  project  success. 

For  the  project  manager  to  successfully  negotiate  issues  on  the  project,  he  or  she  should  first  seek  to  understand 
the  position  of  the  other  party.  If  negotiating  with  a  client,  what  is  the  concern  or  desired  outcome  of  the  client? 
What  are  the  business  drivers  and  personal  drivers  that  are  important  to  the  client?  Without  this  understanding,  it 
is  difficult  to  find  a  solution  that  will  satisfy  the  client.  The  project  manager  should  also  seek  to  understand  what 
outcomes  are  desirable  to  the  project.  Typically,  more  than  one  outcome  is  acceptable.  Without  knowing  what 
outcomes  are  acceptable,  it  is  difficult  to  find  a  solution  that  will  produce  that  outcome. 

One  of  the  most  common  issues  in  formal  negotiations  is  finding  a  mutually  acceptable  price  for  a  service  or  prod¬ 
uct.  Understanding  the  market  value  for  a  product  or  service  will  provide  a  range  for  developing  a  negotiating 
strategy.  The  price  paid  on  the  last  project  or  similar  projects  provides  information  on  the  market  value.  Seeking 
expert  opinions  from  sources  who  would  know  the  market  is  another  source  of  information.  Based  on  this  infor¬ 
mation,  the  project  manager  can  then  develop  an  expected  range  within  the  current  market  from  the  lowest  price 
to  the  highest  price. 

Additional  factors  will  also  affect  the  negotiated  price.  The  project  manager  may  be  willing  to  pay  a  higher  price 
to  assure  an  expedited  delivery  or  a  lower  price  if  delivery  can  be  made  at  the  convenience  of  the  supplier  or 
if  payment  is  made  before  the  product  is  delivered.  Developing  as  many  options  as  possible  provides  a  broader 
range  of  choices  and  increases  the  possibility  of  developing  a  mutually  beneficial  outcome. 

The  goal  of  negotiations  is  not  to  achieve  the  lowest  costs,  although  that  is  a  major  consideration,  but  to  achieve 
the  greatest  value  for  the  project.  If  the  supplier  believes  that  the  negotiations  process  is  fair  and  the  price  is  fair, 


11.  RESOURCE  PLANNING  •  105 


the  project  is  more  likely  to  receive  higher  value  from  the  supplier.  The  relationship  with  the  supplier  can  be 
greatly  influenced  by  the  negotiation  process  and  a  project  manager  who  attempts  to  drive  the  price  unreason¬ 
ably  low  or  below  the  market  value  will  create  an  element  of  distrust  in  the  relationship  that  may  have  negative 
consequences  for  the  project.  A  positive  negotiation  experience  may  create  a  positive  relationship  that  may  be 
beneficial,  especially  if  the  project  begins  to  fall  behind  schedule  and  the  supplier  is  in  a  position  to  help  keep  the 
project  on  schedule. 


Conflict  Resolution 

Conflict  on  a  project  is  to  be  expected  because  of  the  level  of  stress,  lack  of  information  during  early  phases  of  the 
project,  personal  differences,  role  conflicts,  and  limited  resources.  Although  good  planning,  communication,  and 
team  building  can  reduce  the  amount  of  conflict,  conflict  will  still  emerge.  How  the  project  manager  deals  with 
the  conflict  results  in  the  conflict  being  destructive  or  an  opportunity  to  build  energy,  creativity,  and  innovation. 

David  Whetton  and  Kim  Cameron  developed  a  response-to-conflict  model  that  reflected  the  importance  of  the 
issue  balanced  against  the  importance  of  the  relationship  (2005).  The  model  presented  five  responses  to  conflict: 

•  Avoiding 

•  Forcing 

•  Collaborating 

•  Compromising 

•  Accommodating 

Each  of  these  approaches  can  be  effective  and  useful  depending  on  the  situation.  Project  managers  will  use  each 
of  these  conflict  resolution  approaches  depending  on  the  project  manager’s  personal  approach  and  an  assessment 
of  the  situation. 

Most  project  managers  have  a  default  approach  that  has  emerged  over  time  and  is  comfortable.  For  example,  some 
project  managers  find  the  use  of  the  project  manager’s  power  the  easiest  and  quickest  way  to  resolve  problems. 
“Do  it  because  I  said  to”  is  the  mantra  for  project  managers  who  use  forcing  as  the  default  approach  to  resolve 
conflict.  Some  project  managers  find  accommodating  with  the  client  the  most  effective  approach  to  dealing  with 
client  conflict. 

The  effectiveness  of  a  conflict  resolution  approach  will  depend  on  the  situation.  The  forcing  approach  often  suc¬ 
ceeds  in  a  situation  where  a  quick  resolution  is  needed,  and  the  investment  in  the  decision  by  the  parties  involved 
is  low. 

Example:  Resolving  an  Office  Space  Conflict 

Two  senior  managers  both  want  the  office  with  the  window.  The  project  manager  intercedes  with  little  discussion 
and  assigns  the  window  office  to  the  manager  with  the  most  seniority.  The  situation  was  a  low-level  conflict  with 
no  long-range  consequences  for  the  project  and  a  solution  all  parties  could  accept. 
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Sometimes  office  size  and  location  is  culturally  important,  and  this  situation  would  take  more  investment  to 
resolve. 

Example:  Conflict  Over  a  Change  Order 

In  another  example,  the  client  rejected  a  request  for  a  change  order  because  she  thought  the  change  should  have 
been  foreseen  by  the  project  team  and  incorporated  into  the  original  scope  of  work.  The  project  controls  manager 
believed  the  client  was  using  her  power  to  avoid  an  expensive  change  order  and  suggested  the  project  team  refuse 
to  do  the  work  without  a  change  order  from  the  client. 

This  is  a  more  complex  situation,  with  personal  commitments  to  each  side  of  the  conflict  and  consequences  for 
the  project.  The  project  manager  needs  a  conflict  resolution  approach  that  increases  the  likelihood  of  a  mutually 
acceptable  solution  for  the  project.  One  conflict  resolution  approach  involves  evaluating  the  situation,  develop¬ 
ing  a  common  understanding  of  the  problem,  developing  alternative  solutions,  and  mutually  selecting  a  solution. 
Evaluating  the  situation  typically  includes  gathering  data.  In  our  example  of  a  change  order  conflict,  gathering 
data  would  include  a  review  of  the  original  scope  of  work  and  possibly  of  people’s  understandings,  which  might 
go  beyond  the  written  scope.The  second  step  in  developing  a  resolution  to  the  conflict  is  to  restate,  paraphrase, 
and  reframe  the  problem  behind  the  conflict  to  develop  a  common  understanding  of  the  problem.  In  our  example, 
the  common  understanding  may  explore  the  change  management  process  and  determine  that  the  current  change 
management  process  may  not  achieve  the  client’s  goal  of  minimizing  project  changes.  This  phase  is  often  the  most 
difficult  and  may  take  an  investment  of  time  and  energy  to  develop  a  common  understanding  of  the  problem. 

After  the  problem  has  been  restated  and  agreed  on,  alternative  approaches  are  developed.  This  is  a  creative  process 
that  often  means  developing  a  new  approach  or  changing  the  project  plan.  The  result  is  a  resolution  to  the  con¬ 
flict  that  is  mutually  agreeable  to  all  team  members.  If  all  team  members  believe  every  effort  was  made  to  find  a 
solution  that  achieved  the  project  charter  and  met  as  many  of  the  team  member’s  goals  as  possible,  there  will  be  a 
greater  commitment  to  the  agreed-on  solution. 


Delegation 

Delegating  responsibility  and  work  to  others  is  a  critical  project  management  skill.  The  responsibility  for  execut¬ 
ing  the  project  belongs  to  the  project  manager.  Often  other  team  members  on  the  project  will  have  a  functional 
responsibility  on  the  project  and  report  to  a  functional  manager  in  the  parent  organization.  For  example,  the  pro¬ 
curement  leader  for  a  major  project  may  also  report  to  the  organization’s  vice-president  for  procurement.  Although 
the  procurement  plan  for  the  project  must  meet  the  organization’s  procurement  policies,  the  procurement  leader 
on  the  project  will  take  day-to-day  direction  from  the  project  manager.  The  amount  of  direction  given  to  the  pro¬ 
curement  leader,  or  others  on  the  project,  is  the  decision  of  the  project  manager. 

If  the  project  manager  delegates  too  little  authority  to  others  to  make  decisions  and  take  action,  the  lack  of  a  timely 
decision  or  lack  of  action  will  cause  delays  on  the  project.  Delegating  too  much  authority  to  others  who  do  not 
have  the  knowledge,  skills,  or  information  will  typically  cause  problems  that  result  in  delay  or  increased  cost  to 
the  project.  Finding  the  right  balance  of  delegation  is  a  critical  project  management  skill. 

When  developing  the  project  team,  the  project  manager  selects  team  members  with  the  knowledge,  skills,  and 
abilities  to  accomplish  the  work  required  for  the  project  to  be  successful.  Typically,  the  more  knowledge,  skills, 
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abilities,  and  experience  a  project  team  member  brings  to  the  project,  the  more  that  team  member  will  be  paid.  To 
keep  the  project  personnel  costs  lower,  the  project  manager  will  develop  a  project  team  with  the  level  of  experi¬ 
ence  and  the  knowledge,  skills,  and  abilities  to  accomplish  the  work. 

On  smaller,  less  complex  projects,  the  project  manager  can  provide  daily  guidance  to  project  team  members  and 
be  consulted  on  all  major  decisions.  On  larger,  more  complex  projects,  there  are  too  many  important  decisions 
made  every  day  for  the  project  manager  to  be  involved  at  the  same  level,  and  project  team  leaders  are  delegated 
decision-making  authority.  Larger  projects,  with  a  more  complex  profile  will  typically  pay  more  because  of  the 
need  for  the  knowledge  and  experience.  On  larger,  more  complex  projects,  the  project  manager  will  develop  a 
more  experienced  and  knowledgeable  team  that  will  enable  the  project  manager  to  delegate  more  responsibility  to 
these  team  members. 

Example:  Learning  Project  in  Peru 

An  instructional  design  project  in  Peru  was  falling  behind  schedule,  and  a  new  manager  was  assigned  to  the  design 
team,  which  was  the  one  most  behind  schedule.  He  was  an  experienced  project  manager  from  the  United  States 
with  a  reputation  for  meeting  aggressive  schedules.  However,  he  failed  to  see  that  as  a  culture,  Peruvians  do  a 
great  deal  more  socializing  than  teams  in  the  U.S.  The  project  manager’s  communication  with  the  team  was  then 
limited  because  he  did  not  go  out  and  spend  time  with  them,  and  his  team  did  not  develop  trust  or  respect  for  him. 
Due  to  these  cultural  differences,  the  project  fell  further  behind,  and  another  personnel  change  had  to  be  made  at 
a  significant  cost  of  time,  trust,  and  money. 

The  project  manager  must  have  the  skills  to  evaluate  the  knowledge,  skills,  and  abilities  of  project  team  members 
and  evaluate  the  complexity  and  difficulty  of  the  project  assignment.  Often  project  managers  want  project  team 
members  they  have  worked  with  in  the  past.  Because  the  project  manager  knows  the  skill  level  of  the  team  mem¬ 
ber,  project  assignments  can  be  made  quickly  with  less  supervision  than  with  a  new  team  member  with  whom  the 
project  manager  has  little  or  no  experience. 

Delegation  is  the  art  of  creating  a  project  organizational  structure  with  the  work  organized  into  units  that  can  be 
managed.  Delegation  is  the  process  of  understanding  the  knowledge,  skills,  and  abilities  needed  to  manage  that 
work  and  then  matching  the  team  members  with  the  right  skills  to  do  that  work.  Good  project  managers  are  good 
delegators. 


Adjusting  Leadership  Styles 

Remember  that  personality  traits  reflect  an  individual’s  preferences,  not  their  limitations.  It  is  important  to  under¬ 
stand  that  individuals  can  still  function  in  situations  for  which  they  are  not  best  suited.  It  is  also  important  to 
realize  that  you  can  change  your  leadership  style  according  to  the  needs  of  your  team  and  the  particular  project’s 
attributes  and  scope. 

For  example,  a  project  leader  who  is  more  thinking  (T)  than  feeling  (F)  (according  to  the  Myers-Briggs  model) 
would  need  to  work  harder  to  be  considerate  of  how  team  members  who  are  more  feeling  (F)  might  react  if  they 
were  singled  out  in  a  meeting  because  they  were  behind  schedule.  If  individuals  knows  their  own  preferences 
and  which  personality  types  are  most  successful  in  each  type  of  project  or  project  phase,  they  can  set  goals  for 
improvement  in  their  ability  to  perform  in  those  areas  that  are  not  their  natural  preference. 
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Another  individual  goal  is  to  examine  which  conflict  resolution  styles  you  are  least  comfortable  and  work  to 
improve  those  styles  so  that  they  can  be  used  when  they  are  more  appropriate  than  your  default  style. 


Working  with  Groups  and  Teams 

A  team  is  a  collaboration  of  people  with  different  personalities  that  is  led  by  a  person  with  a  favored  leadership 
style.  Managing  the  interactions  of  these  personalities  and  styles  as  a  group  is  an  important  aspect  of  project  man¬ 
agement. 

Trust 

Trust  is  the  foundation  for  all  relationships  within  a  project.  Without  a  minimum  level  of  trust,  communication 
breaks  down,  and  eventually  the  project  suffers  in  the  form  of  costs  increasing  and  schedules  slipping.  Often, 
when  reviewing  a  project  where  the  performance  problems  have  captured  the  attention  of  upper  management, 
the  evidence  of  problems  is  the  increase  in  project  costs  and  the  slippage  in  the  project  schedule.  The  underlying 
cause  is  usually  blamed  on  communication  breakdown.  With  deeper  investigation,  the  communication  breakdown 
is  associated  with  a  breakdown  in  trust. 

On  projects,  trust  is  the  filter  through  which  we  screen  information  that  is  shared  and  the  filter  we  use  to  screen 
information  we  receive.  The  more  trust  that  exists,  the  easier  it  is  for  information  to  flow  through  the  filters.  As 
trust  diminishes,  the  filters  become  stronger  and  information  has  a  harder  time  getting  through,  and  projects  that 
are  highly  dependent  on  an  information-rich  environment  will  suffer  from  information  deprivation. 

Contracts  and  Trust  Relationships 

A  project  typically  begins  with  a  charter  or  contract.  A  contract  is  a  legal  agreement  that  includes  penalties  for  any 
behavior  or  results  not  achieved.  Contracts  are  based  on  an  adversarial  paradigm  and  do  not  lend  themselves  to 
creating  an  environment  of  trust.  Contracts  and  charters  are  necessary  to  clearly  establish  the  scope  of  the  project, 
among  other  things,  but  they  are  not  conducive  to  establishing  a  trusting  project  culture. 

A  relationship  of  mutual  trust  is  less  formal  but  vitally  important.  When  a  person  or  team  enters  into  a  relationship 
of  mutual  trust,  each  person’s  reputation  and  self-respect  are  the  drivers  in  meeting  the  intent  of  the  relationship. 
A  relationship  of  mutual  trust  within  the  context  of  a  project  is  a  commitment  to  an  open  and  honest  relationship. 
There  is  nothing  that  enforces  the  commitments  in  the  relationship  except  the  integrity  of  the  people  involved. 
Smaller,  less  complex  projects  can  operate  within  the  boundaries  of  a  legal  contract,  but  larger,  more  complex 
projects  must  develop  a  relationship  of  mutual  trust  to  be  successful. 

Types  of  Trust 

Svenn  Lindskold  describes  four  kinds  of  trust  (1978): 

•  Objective  credibility.  A  personal  characteristic  that  reflects  the  truthfulness  of  an  individual  that  can  be 
checked  against  observable  facts. 


Attribution  of  benevolence.  A  form  of  trust  that  is  built  on  the  examination  of  the  person’s  motives  and  the 
conclusion  that  they  are  not  hostile. 
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•  N on-manipulative  trust.  A  form  of  trust  that  correlates  to  a  person’s  self-interest  and  the  predictability  of  a 
person’s  behavior  in  acting  consistent  in  that  self-interest. 

•  High  cost  of  lying.  The  type  of  trust  that  emerges  when  persons  in  authority  raise  the  cost  of  lying  so  high 
that  people  will  not  lie  because  the  penalty  will  be  too  high. 

Creating  Trust 

Building  trust  on  a  project  begins  with  the  project  manager.  On  complex  projects,  the  assignment  of  a  project  man¬ 
ager  with  a  high  trust  reputation  can  help  establish  the  trust  level  needed.  The  project  manager  can  also  establish 
the  cost  of  lying  in  a  way  that  communicates  an  expectation  and  a  value  for  trust  on  the  project.  Project  managers 
can  also  assure  that  the  official  goals  (stated  goals)  and  operational  goals  (goals  that  are  reinforced)  are  aligned. 
The  project  manager  can  create  an  atmosphere  where  informal  communication  is  expected  and  reinforced. 

The  informal  communication  is  important  to  establishing  personal  trust  among  team  members  and  with  the  client. 
Allotting  time  during  project  start-up  meetings  to  allow  team  members  to  develop  a  personal  relationship  is  impor¬ 
tant  to  establishing  the  team  trust.  The  informal  discussion  allows  for  a  deeper  understanding  of  the  whole  person 
and  creates  an  atmosphere  where  trust  can  emerge. 

Example:  High  Cost  of  Lying  in  a  Charleston  Project 

On  a  project  in  Charleston,  South  Carolina,  the  client  was  asking  for  more  and  more  backup  to  information  from 
the  project.  The  project  manager  visited  the  client  to  better  understand  the  reporting  requirements  and  discov¬ 
ered  the  client  did  not  trust  the  reports  coming  from  the  project  and  wanted  validating  material  for  each  report. 
After  some  candid  discussion,  the  project  manager  discovered  that  one  of  the  project  team  members  had  provided 
information  to  the  client  that  was  inaccurate.  The  team  member  had  made  a  mistake  but  had  not  corrected  it  with 
the  client,  hoping  that  the  information  would  get  lost  in  the  stream  of  information  from  the  project.  The  project 
manager  removed  the  team  member  from  the  project  for  two  main  reasons.  The  project  manager  established  that 
the  cost  of  lying  was  high.  The  removal  communicated  to  the  project  team  an  expectation  of  honesty.  The  project 
manager  also  reinforced  a  covenant  with  the  client  that  reinforced  the  trust  in  the  information  the  project  pro¬ 
vided.  The  requests  for  additional  information  declined,  and  the  trust  relationship  between  project  personnel  and 
the  client  remained  high. 

Small  events  that  reduce  trust  often  take  place  on  a  project  without  anyone  remembering  what  happened  to  create 
the  environment  of  distrust.  Taking  fast  and  decisive  action  to  establish  a  high  cost  of  lying,  communicating  the 
expectation  of  honesty,  and  creating  an  atmosphere  of  trust  are  critical  steps  a  project  manager  can  take  to  ensure 
the  success  of  complex  projects. 

Project  managers  can  also  establish  expectations  of  team  members  to  respect  individual  differences  and  skills, 
look  and  react  to  the  positives,  recognize  each  other’s  accomplishments,  and  value  people’s  self-esteem  to  increase 
a  sense  of  the  benevolent  intent. 

Managing  Team  Meetings 

Team  meetings  are  conducted  differently  depending  on  the  purpose  of  the  meeting,  the  leadership  style  that  is 
appropriate  for  the  meeting,  and  the  personality  types  of  the  members  of  the  team. 
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Action  Item  Meetings 

Action  item  meetings  are  short  meetings  to  develop  a  common  understanding  of  what  the  short-term  priorities  are 
for  the  project,  individual  roles,  and  expectations  for  specific  activities.  This  type  of  meeting  is  for  sharing,  not 
problem  solving.  Any  problems  that  emerge  from  the  discussion  are  assigned  to  a  person,  and  another  meeting  is 
established  to  address  the  issue.  Action  item  meetings  focus  on  short-term  activities,  usually  less  than  a  week  in 
duration. 

The  action  item  meeting  is  fact  based  and  information  oriented.  It  is  a  left-brain-type  focus.  The  action  item  meet¬ 
ing  has  very  little  dialogue  except  to  ask  clarification  questions.  If  discussion  is  needed  or  disagreement  is  not 
easily  resolved,  another  problem-solving  meeting  is  established  to  deal  with  that  issue.  On  smaller  topics,  that 
meeting  might  take  place  immediately  after  the  action  item  meeting  and  only  include  those  people  with  an  interest 
in  the  outcome  of  the  discussion. 

The  project  manager  keeps  the  successful  action  item  meeting  short  in  duration  and  focused  on  only  those  items  of 
information  needed  for  the  short-term  project  plan.  The  project  manager  will  restate  the  common  understandings 
of  what  activities  are  priorities  and  who  will  be  responsible  for  the  activities.  Often  these  meetings  can  include  a 
review  of  safety  procedures  or  security  procedures  when  these  issues  are  important  to  the  project.  The  leadership 
approach  to  action  item  meetings  focuses  on  data,  actions,  and  commitments.  Although  the  project  manager  may 
observe  stresses  between  project  team  members  or  other  issues,  they  are  not  addressed  in  this  meeting.  These  are 
fact-based  meetings.  If  issues  begin  to  arise  between  people,  the  project  manager  will  develop  other  opportunities 
to  address  these  issues  in  another  forum.  Using  the  Myers-Briggs  descriptions,  team  members  who  favor  thinking 
more  than  feeling  and  judging  more  than  perceiving  are  more  comfortable  with  this  type  of  meeting. 

Management  Meetings 

Management  meetings  are  longer  in  duration  and  are  focused  on  planning.  They  are  oriented  toward  developing 
plans,  tracking  progress  of  existing  plans,  and  making  adjustments  to  plans  in  response  to  new  information. 

These  meetings  include  focused  discussion  on  generating  a  common  understanding  of  the  progress  of  the  existing 
plan.  This  discussion  is  based  on  quantitative  information  provided  on  the  progress  of  the  schedule  and  other  data, 
but  the  discussion  is  qualitative  in  evaluating  the  data  to  develop  a  more  complete  understanding  of  the  data.  The 
experience  and  opinions  of  the  project  leaders  are  solicited,  and  disagreement  about  meaning  of  the  data  is  even 
encouraged  to  develop  a  deeper  understanding  of  the  data.  Through  this  discussion,  a  common  understanding  of 
the  status  of  the  project  should  emerge,  and  the  project  manager  invites  discussion,  invites  people  to  offer  their 
thoughts,  and  assures  that  disagreements  are  positive  discussions  about  interpretation  of  the  information  and  that 
disagreements  do  not  become  personal. 

Management  meetings  also  focus  on  developing  mid-term  goals.  For  larger,  more  complex  projects,  the  goals 
may  be  monthly  or  even  quarterly.  For  smaller  or  less  complex  projects,  weekly  goals  will  provide  the  focus.  The 
project  manager  focuses  the  discussion  on  the  broad  priorities  for  the  next  period  and  includes  all  the  functional 
leaders  in  the  discussion.  The  goals  that  emerge  from  the  discussion  should  represent  a  common  understanding  of 
the  priorities  of  the  project  for  the  next  term. 


For  example,  during  the  early  phases  of  a  project,  the  team  is  focused  on  developing  a  conceptual  understanding 
of  the  project.  A  major  milestone  on  complex  projects  is  typically  the  completion  of  the  conceptual  plan.  The  pro- 
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ject  manager  would  lead  a  discussion  on  what  needs  to  be  accomplished  to  meet  the  project  milestone  and  asks 
what  potential  barriers  exist  and  what  key  resources  are  needed.  From  the  discussion,  the  project  team  develops  a 
few  key  goals  that  integrate  the  various  functions  of  the  project  team  and  focus  the  team  on  priorities. 

The  following  are  some  examples  of  goals  during  the  conceptual  phase: 

•  Developing  a  list  of  the  procurement  long-lead  items  and  defining  critical  dates 

•  Developing  a  human  resources  plan  that  identifies  critical  positions 

•  Developing  and  building  agreement  with  the  client  on  the  project  scope  of  work 

Each  of  these  goals  is  measurable  and  has  a  time  frame  specified.  They  can  be  developed  as  positive  motivators 
and  will  take  the  project  leaders  and  most  of  the  project  team  to  accomplish.  They  develop  a  general  understanding 
of  the  priorities  and  are  easy  to  remember. 

Management  meetings  are  a  combination  of  left-brain  thinking,  which  is  fact  based,  and  right-brain  thinking, 
which  is  creative  and  innovative.  Using  the  Myers-Briggs  terminology,  team  members  who  prefer  feeling  over 
thinking  and  perceiving  over  judging  can  contribute  ideas  and  perspectives  on  the  project  that  the  more  fact-ori¬ 
ented  members  might  miss. 

The  project  manager  allows  and  encourages  conversation  in  developing  and  evaluating  the  goals  but  focuses  the 
discussion  on  the  goals  and  obstacles.  Management  meetings  take  on  a  different  focus  during  the  month.  Meetings 
at  the  beginning  of  the  month  spend  time  addressing  the  progress  and  potential  barriers  to  the  goals  developed 
the  previous  month.  During  the  middle  of  the  month,  the  project  manager  leads  the  team  to  develop  next  month’s 
goals  as  the  team  also  works  on  the  current  month’s  goals.  Toward  the  end  of  the  month  as  the  goals  for  the  month 
are  accomplished,  the  meeting  focuses  more  on  the  next  month,  enabling  the  team  to  remain  goal  focused  during 
the  life  of  the  project. 

Management  meetings  are  also  an  opportunity  to  discover  obstacles  to  goal  achievement.  The  project  team  real¬ 
locates  resources  or  develops  alternative  methods  for  accomplishing  the  goals.  As  the  project  team  discusses  the 
progress  of  project  goals,  the  project  manager  explores  possible  obstacles  and  encourages  exposing  potential  prob¬ 
lems  in  achieving  goals.  The  project  manager  focuses  the  team  on  finding  solutions  and  avoids  searching  for 
blame. 

The  project  manager  uses  a  facilitative  leadership  approach,  encouraging  the  management  team  to  contribute  their 
ideas,  and  builds  consensus  on  what  goals  will  bring  the  appropriate  focus.  The  project  manager  keeps  the  focus 
on  developing  the  goals,  tracking  progress,  identifying  barriers,  and  making  adjustments  to  accomplish  the  man¬ 
agement  goals.  Although  there  are  typically  meetings  for  scheduling  and  procurement  and  other  meetings  where 
goals  are  established  and  problems  solved,  the  management  meeting  and  the  goal  development  process  create 
alignment  among  the  project  leadership  on  the  items  critical  to  the  project’s  success. 

Leadership  Meetings 

Leadership  meetings  are  held  less  frequently  and  are  longer  in  length.  These  meetings  are  used  by  the  project  man¬ 
ager  to  reflect  on  the  project,  explore  the  larger  issues  of  the  project,  and  back  away  from  the  day-to-day  problem 
solving.  The  project  manager  will  create  a  safe  environment  for  sharing  thoughts  and  evaluations  of  issues  that 
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are  less  data  oriented.  This  is  a  right-brained,  creative  meeting  that  focuses  on  the  people  issues  of  the  project:  the 
relationship  with  the  client,  vendors,  and  project  team.  Team  members  who  favor  feeling,  perceiving,  and  intu¬ 
ition  often  contribute  valuable  insights  in  this  type  of  meeting.  The  team  might  also  share  perceptions  by  upper 
management  and  perceptions  of  the  community  in  which  the  project  is  being  executed.  Where  the  time  frame  for 
action  item  meetings  is  in  weeks  and  management  meetings  is  in  months,  the  time  frame  for  leadership  meetings 
is  longer  and  takes  in  the  entire  length  and  impact  of  the  project. 

The  project  manager’s  meeting  management  skill  includes  creating  the  right  meeting  atmosphere  for  the  team  dis¬ 
cussion  that  is  needed.  For  discussions  based  on  data  and  facts,  the  project  manager  creates  the  action  item  type 
meeting.  The  conversation  is  focused  on  sharing  information  and  clarification.  The  conversation  for  leadership 
meetings  is  the  opposite.  Discussion  is  more  open  ended  and  focused  on  creativity  and  innovation.  Because  each 
type  of  meeting  requires  a  different  meeting  atmosphere,  mixing  the  purposes  of  a  meeting  will  make  it  difficult 
for  the  project  manager  to  develop  and  maintain  the  appropriate  kind  of  conversation. 

Skilled  project  managers  know  what  type  of  meeting  is  needed  and  how  to  develop  an  atmosphere  to  support  the 
meeting  type.  Meetings  of  the  action  item  type  are  focused  on  information  sharing  with  little  discussion.  They 
require  efficient  communication  of  plans,  progress,  and  other  information  team  members  need  to  plan  and  execute 
daily  work.  Management  type  meetings  are  focused  on  developing  and  progressing  goals.  Leadership  meetings 
are  more  reflective  and  focused  on  the  project  mission  and  culture. 

These  three  types  of  meetings  do  not  cover  all  the  types  of  project  meetings.  Specific  problem-solving,  vendor 
evaluation,  and  scheduling  meetings  are  examples  of  typical  project  meetings.  Understanding  what  kinds  of  meet¬ 
ings  are  needed  on  the  project  and  creating  the  right  focus  for  each  meeting  type  is  a  critical  project  management 
skill. 

Types  of  Teams 

Teams  can  outperform  individual  team  members  in  several  situations.  The  effort  and  time  invested  in  developing 
a  team  and  the  work  of  the  team  are  large  investments  of  project  resources,  and  the  payback  is  critical  to  project 
success.  Determining  when  a  team  is  needed  and  then  chartering  and  supporting  the  development  and  work  of  the 
team  are  other  critical  project  management  abilities. 

Teams  are  effective  in  several  project  situations: 

•  When  no  one  person  has  the  knowledge,  skills,  and  abilities  to  either  understand  or  solve  the  problem 

•  When  a  commitment  to  the  solution  is  needed  by  large  portions  of  the  project  team 

•  When  the  problem  and  solution  cross  project  functions 

•  When  innovation  is  required 

Individuals  can  outperform  teams  on  some  occasions.  An  individual  tackling  a  problem  consumes  fewer  resources 
than  a  team  and  can  operate  more  efficiently — as  long  as  the  solution  meets  the  project’s  needs.  A  person  is  most 
appropriate  in  the  following  situations: 


When  speed  is  important 
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•  When  one  person  has  the  knowledge,  skills,  and  resources  to  solve  the  problem 

•  When  the  activities  involved  in  solving  the  problem  are  very  detailed 

•  When  the  actual  document  needs  to  be  written  (Teams  can  provide  input,  but  writing  is  a  solitary  task.) 

In  addition  to  knowing  when  a  team  is  appropriate,  the  project  manager  must  also  understand  what  type  of  team 
will  function  best. 

Functional  Teams 

A  functional  team  refers  to  the  team  approach  related  to  the  project  functions.  The  engineering  team,  the  procure¬ 
ment  team,  and  the  project  controls  team  are  examples  of  functional  teams  within  the  project.  On  a  project  with 
a  low  complexity  profile  that  includes  low  technological  challenges,  good  team  member  experience,  and  a  clear 
scope  of  work,  the  project  manager  can  utilize  well-defined  functional  teams  with  clear  expectations,  direction, 
and  strong  vertical  communication. 

Cross-Functional  Teams 

Cross-functional  teams  address  issues  and  work  processes  that  include  two  or  more  of  the  functional  teams.  The 
team  members  are  selected  to  bring  their  functional  expertise  to  addressing  project  opportunities. 

Example:  Cross-Functional  Teamwork 

A  cross-functional  project  team  in  Tennessee  was  assigned  to  develop  a  project  approach  to  drafting,  shooting,  and 
editing  educational  videos  without  storing  the  videos  on  the  school  server.  Although  the  complexity  of  this  goal 
is  primarily  related  to  creating  the  videos  and  procuring  editing  equipment,  the  planning  involved  coordination 
of  the  script  drafting,  procurement  of  equipment  and  talent,  and  establishment  of  project  controls.  Team  members 
from  each  of  these  functions  developed  and  tracked  a  plan  to  meet  the  project  goal.  Because  they  communicated 
so  frequently  and  clearly,  the  cross-functional  team  was  successful  in  designing  a  process  and  executing  the  plan 
in  a  way  that  saved  three  weeks  on  the  video  schedule  and  several  thousand  dollars  in  cost  by  hosting  off-site. 

Problem-Solving  Teams 

Problem-solving  teams  are  assigned  to  address  specific  issues  that  arise  during  the  life  of  the  project.  The  project 
leadership  includes  members  that  have  the  expertise  to  address  the  problem.  The  team  is  chartered  to  address  that 
problem  and  then  disband. 


Qualitative  Assessment  of  Project  Performance 

Project  managers  should  provide  an  opportunity  to  ask  such  questions  as  “What  is  your  gut  feeling  about  how  the 
project  going?”  and  “How  do  you  think  our  client  perceives  the  project?”  This  creates  the  opportunity  for  reflec¬ 
tion  and  dialogue  around  larger  issues  on  the  project.  The  project  manager  creates  an  atmosphere  for  the  team  to 
go  beyond  the  data  and  search  for  meaning.  This  type  of  discussion  and  reflection  is  very  difficult  in  the  stress  of 
day-to-day  problem  solving. 

The  project  manager  has  several  tools  for  developing  good  quantitative  information — based  on  numbers  and  mea- 
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surements — such  as  the  project  schedules,  budgets  and  budget  reports,  risk  analysis,  and  goal  tracking.  This  quan¬ 
titative  information  is  essential  to  understanding  the  current  status  and  trends  on  the  project.  Just  as  important  is 
the  development  of  qualitative  information — comparisons  of  qualities — such  as  judgments  made  by  expert  team 
members  that  go  beyond  the  quantitative  data  provided  in  a  report.  Some  would  label  this  the  “gut  feeling”  or 
intuition  of  experienced  project  managers. 

The  Humm  Factor  is  a  survey  tool  developed  by  Russ  Darnall  to  capture  the  thoughts  of  project  participants.  It 
derived  its  name  from  a  project  manager  who  always  claimed  he  could  tell  you  more  by  listening  to  the  hum  of 
the  project  than  reading  all  the  project  reports.  “Do  you  feel  the  project  is  doing  the  things  it  needs  to  do  to  stay 
on  schedule?”  and  “Is  the  project  team  focused  on  project  goals?”  are  the  types  of  questions  that  can  be  included 
in  the  Humm  Factor.  It  is  distributed  on  a  weekly  or  less  frequent  basis  depending  on  the  complexity  profile  of 
the  project.  A  project  with  a  high  level  of  complexity  due  to  team-based  and  cultural  issues  will  be  surveyed  more 
frequently. 

The  qualitative  responses  are  converted  to  a  quantitative  value  as  a  score  from  1  to  10.  Responses  are  tracked  by 
individuals  and  the  total  project,  resulting  in  qualitative  comparisons  over  time.  The  project  team  reviews  the  rat¬ 
ings  regularly,  looking  for  trends  that  indicate  an  issue  may  be  emerging  on  the  project  that  might  need  exploring. 

Example:  Humm  Survey  Uncovers  Concerns 

On  a  project  in  South  Carolina,  the  project  surveyed  the  project  leadership  with  a  Humm  Survey  each  week.  The 
Humm  Factor  indicated  an  increasing  worry  about  the  schedule  beginning  to  slip  when  the  schedule  reports  indi¬ 
cated  that  everything  was  according  to  plan.  When  the  project  manager  began  trying  to  understand  why  the  Humm 
Factor  was  showing  concerns  about  the  schedule,  he  discovered  an  apprehension  about  the  performance  of  a  crit¬ 
ical  project  supplier.  When  he  asked  team  members,  they  responded,  “It  was  the  way  they  answered  the  phone  or 
the  hesitation  when  providing  information — something  didn’t  feel  right.” 

The  procurement  manager  visited  the  supplier  and  discovered  the  company  was  experiencing  financial  problems 
and  had  serious  cash  flow  problems.  The  project  manager  was  able  to  develop  a  plan  to  help  the  supplier  through 
the  period,  and  the  supplier  eventually  recovered.  The  project  was  able  to  meet  performance  goals.  The  Humm 
Factor  survey  provided  a  tool  for  members  of  the  project  team  to  express  concerns  that  were  based  on  very  soft 
data,  and  the  project  team  was  able  to  discover  a  potential  problem. 

Another  project  team  used  the  Humm  Factor  to  survey  the  client  monthly.  The  completed  surveys  went  to  a  person 
who  was  not  on  the  project  team  to  provide  anonymity  to  the  responses.  The  responses  were  discussed  at  the 
monthly  project  review  meetings,  and  the  project  manager  summarized  the  results  and  addressed  all  the  concerns 
expressed  in  the  report.  “I  don’t  feel  my  concerns  are  being  heard”  was  one  response  that  began  increasing  during 
the  project,  and  the  project  manager  spent  a  significant  portion  of  the  next  project  review  meeting  attempting  to 
understand  what  this  meant.  The  team  discovered  that  as  the  project  progressed  toward  major  milestones,  the  pro¬ 
ject  team  became  more  focused  on  solving  daily  problems,  spent  more  time  in  meetings,  and  their  workday  was 
becoming  longer.  The  result  was  fewer  contacts  with  the  clients,  slower  responses  in  returning  phone  calls,  and 
much  fewer  coffee  breaks  where  team  members  could  casually  discuss  the  project  with  the  client. 

The  result  of  the  conversation  led  to  better  understanding  by  both  the  project  team  and  client  team  of  the  change 
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in  behavior  based  on  the  current  phase  of  the  project  and  the  commitment  to  developing  more  frequent  informal 
discussion  about  the  project. 


Creating  a  Project  Culture 

Project  managers  have  a  unique  opportunity  during  the  start-up  of  a  project.  They  create  a  project  culture,  some¬ 
thing  organizational  managers  seldom  have  a  chance  to  do.  In  most  organizations,  the  corporate  or  organizational 
culture  has  developed  over  the  life  of  the  organization,  and  people  associated  with  the  organization  understand 
what  is  valued,  what  has  status,  and  what  behaviors  are  expected.  Edgar  Schein  identified  three  distinct  levels  in 
organizational  culture. 

1.  Artifacts  and  behaviours 

2.  Espoused  values 

3.  Assumptions 

Artifacts  are  the  visible  elements  in  a  culture  and  they  can  be  recognized  by  people  not  part  of  the  culture. 
Espoused  values  are  the  organization’s  stated  values  and  rules  of  behavior.  Shared  basic  assumptions  are  the 
deeply  embedded,  taken-for-granted  behaviors  that  are  usually  unconscious,  but  constitute  the  essence  of  culture. 

Characteristics  of  Project  Culture 

A  project  culture  represents  the  shared  norms,  beliefs,  values,  and  assumptions  of  the  project  team.  Understanding 
the  unique  aspects  of  a  project  culture  and  developing  an  appropriate  culture  to  match  the  complexity  profile  of 
the  project  are  important  project  management  abilities. 

Culture  is  developed  through  the  communication  of: 

•  The  priority 

•  The  given  status 

•  The  alignment  of  official  and  operational  rules 

Official  rules  are  the  rules  that  are  stated,  and  operational  rules  are  the  rules  that  are  enforced.  Project  managers 
who  align  official  and  operational  rules  are  more  effective  in  developing  a  clear  and  strong  project  culture  because 
the  project  rules  are  among  the  first  aspects  of  the  project  culture  to  which  team  members  are  exposed  when 
assigned  to  the  project. 

Example:  Operational  Rules  on  a  Multi-site  Project 

During  an  instructional  design  project  that  required  individuals  to  collaborate  remotely,  an  official  rule  had  been 
established  that  individuals  would  back  up  their  work  in  a  location  other  than  the  shared  folders  they  were  using 
every  week.  It  did  not  take  long,  however,  for  everyone  involved  to  see  that  one  member  was  actively  backing 
up  all  work.  Believing  that  was  sufficient,  the  operational  rule  became  simply  leaving  the  backing  up  to  a  single 
individual.  They  assumed  that  official  rules  could  be  ignored  if  they  were  difficult  to  obey. 
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When  this  individual  fell  ill,  however,  no  one  picked  up  the  slack  and  followed  the  official  rule.  When  some  files 
were  corrupted,  the  team  found  that  their  most  recent  backups  were  weeks  old,  resulting  in  redoing  a  lot  of  work. 
The  difference  between  the  official  rules  and  the  operational  rules  of  the  project  created  a  culture  that  made  com¬ 
munication  of  the  priorities  more  difficult. 

In  addition  to  official  and  operational  rules,  the  project  leadership  communicates  what  is  important  by  the  use  of 
symbols,  storytelling,  rituals,  rewards  or  punishments,  and  taboos. 

Example:  Creating  a  Culture  of  Collaboration 

A  project  manager  met  with  his  team  prior  to  the  beginning  of  an  instructional  design  project.  The  team  was 
excited  about  the  prestigious  project  and  the  potential  for  career  advancement  involved.  With  this  increased  com¬ 
petitive  aspect  came  the  danger  of  selfishness  and  backstabbing.  The  project  leadership  team  told  stories  of  previ¬ 
ous  projects  where  people  were  fired  for  breaking  down  the  team  efforts  and  often  shared  inspirational  examples 
of  how  teamwork  created  unprecedented  successes — an  example  of  storytelling.  Every  project  meeting  started 
with  teambuilding  exercises — a  ritual — and  any  display  of  hostility  or  separatism  was  forbidden — taboo — and 
was  quickly  and  strongly  cut  off  by  the  project  leadership  if  it  occurred. 

Culture  guides  behavior  and  communicates  what  is  important  and  is  useful  for  establishing  priorities.  On  projects 
that  have  a  strong  culture  of  trust,  team  members  feel  free  to  challenge  anyone  who  breaks  a  confidence,  even 
managers.  The  culture  of  integrity  is  stronger  than  the  cultural  aspects  of  the  power  of  management. 


Innovation  on  Projects 

The  requirement  of  innovation  on  projects  is  influenced  by  the  nature  of  the  project.  Some  projects  are  chartered 
to  develop  a  solution  to  a  problem,  and  innovation  is  a  central  ingredient  of  project  success.  The  lack  of  avail¬ 
ability  of  education  to  the  world  at  large  prompted  the  open  education  movement,  a  highly  innovative  endeavor, 
which  resulted  in  the  textbook  you  are  now  reading.  Innovation  is  also  important  to  developing  methods  of  lower¬ 
ing  costs  or  shortening  the  schedule.  Traditional  project  management  thinking  provides  a  trade-off  between  cost, 
quality,  and  schedule.  A  project  sponsor  can  typically  shorten  the  project  schedule  with  an  investment  of  more 
money  or  a  lowering  of  quality.  Finding  innovative  solutions  can  sometimes  lower  costs  while  also  saving  time 
and  maintaining  the  quality. 

Innovation  is  a  creative  process  that  requires  both  fun  and  focus.  Stress  is  a  biological  reaction  to  perceived 
threats.  Stress,  at  appropriate  levels,  can  make  the  work  environment  interesting  and  even  challenging.  Many  peo¬ 
ple  working  on  projects  enjoy  a  high-stress,  exciting  environment.  When  the  stress  level  is  too  high,  the  biological 
reaction  increases  blood  flow  to  the  emotional  parts  of  the  brain  and  decreases  the  blood  flow  to  the  creative  parts 
of  the  brain,  making  creative  problem  solving  more  difficult.  Fun  reduces  the  amount  of  stress  on  the  project. 
Project  managers  recognize  the  benefits  of  balancing  the  stress  level  on  the  project  with  the  need  to  create  an 
atmosphere  that  enables  creative  thought. 

Example:  Stress  Managed  on  a  Website  Design  Project 

When  a  project  manager  visited  the  team  tasked  with  designing  the  website  for  a  project,  she  found  that  most  of 
the  members  were  feeling  a  great  deal  of  stress.  As  she  probed  to  find  the  reason  behind  the  stress,  she  found  that 
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in  addition  to  designing,  the  team  was  increasingly  facing  the  need  to  build  the  website  as  well.  As  few  of  them 
had  the  necessary  skills,  they  were  wasting  time  that  could  be  spent  designing  trying  to  learn  building  skills.  Once 
the  project  manager  was  able  to  identify  the  stress  as  well  as  its  cause,  she  was  able  to  provide  the  team  with  the 
support  it  needed  to  be  successful. 

Exploring  opportunities  to  create  savings  takes  an  investment  of  time  and  energy,  and  on  a  time-sensitive  project, 
the  project  manager  must  create  the  motivation  and  the  opportunity  for  creative  thinking. 
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12.  Budget  Planning 


ADRIENNE  WATT 


Every  project  boils  down  to  money.  If  you  had  a  bigger  budget,  you  could  probably  get  more  people  to  do  your 
project  more  quickly  and  deliver  more.  That’s  why  no  project  plan  is  complete  until  you  come  up  with  a  budget. 
But  no  matter  whether  your  project  is  big  or  small,  and  no  matter  how  many  resources  and  activities  are  in  it,  the 
process  for  figuring  out  the  bottom  line  is  always  the  same. 

It  is  important  to  come  up  with  detailed  estimates  for  all  the  project  costs.  Once  this  is  compiled,  you  add  up  the 
cost  estimates  into  a  budget  plan.  It  is  now  possible  to  track  the  project  according  to  that  budget  while  the  work  is 
ongoing. 

Often,  when  you  come  into  a  project,  there  is  already  an  expectation  of  how  much  it  will  cost  or  how  much  time  it 
will  take.  When  you  make  an  estimate  early  in  the  project  without  knowing  much  about  it,  that  estimate  is  called  a 
rough  order-of-magnitude  estimate  (or  a  ballpark  estimate).  This  estimate  will  become  more  refined  as  time  goes 
on  and  you  learn  more  about  the  project.  Here  are  some  tools  and  techniques  for  estimating  cost: 

•  Determination  of  resource  cost  rates:  People  who  will  be  working  on  the  project  all  work  at  a  specific 
rate.  Any  materials  you  use  to  build  the  project  (e.g.,  wood  or  wiring)  will  be  charged  at  a  rate  too.  Deter¬ 
mining  resource  costs  means  figuring  out  what  the  rate  for  labor  and  materials  will  be. 

•  Vendor  bid  analysis:  Sometimes  you  will  need  to  work  with  an  external  contractor  to  get  your  project 
done.  You  might  even  have  more  than  one  contractor  bid  on  the  job.  This  tool  is  about  evaluating  those  bids 
and  choosing  the  one  you  will  accept. 

•  Reserve  analysis:  You  need  to  set  aside  some  money  for  cost  overruns.  If  you  know  that  your  project  has  a 
risk  of  something  expensive  happening,  it  is  better  to  have  some  cash  available  to  deal  with  it.  Reserve 
analysis  means  putting  some  cash  away  in  case  of  overruns. 

•  Cost  of  quality:  You  will  need  to  figure  the  cost  of  all  your  quality-related  activities  into  the  overall  budget. 
Since  it’s  cheaper  to  find  bugs  earlier  in  the  project  than  later,  there  are  always  quality  costs  associated  with 
everything  your  project  produces.  Cost  of  quality  is  just  a  way  of  tracking  the  cost  of  those  activities.  It  is 
the  amount  of  money  it  takes  to  do  the  project  right. 

Once  you  apply  all  the  tools  in  this  process,  you  will  arrive  at  an  estimate  for  how  much  your  project  will  cost.  It’s 
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important  to  keep  all  of  your  supporting  estimate  information.  That  way,  you  know  the  assumptions  made  when 
you  were  coming  up  with  the  numbers.  Now  you  are  ready  to  build  your  budget  plan. 


Estimating  Costs  to  Compare  and  Select  Projects 

During  the  conceptual  phase  when  project  selection  occurs,  economic  factors  are  an  important  consideration 
in  choosing  between  competing  projects.  To  compare  the  simple  paybacks  or  internal  rates  of  return  between  pro¬ 
jects,  an  estimate  of  the  cost  of  each  project  is  made.  The  estimates  must  be  accurate  enough  so  that  the  com¬ 
parisons  are  meaningful,  but  the  amount  of  time  and  resources  used  to  make  the  estimates  should  be  appropriate 
to  the  size  and  complexity  of  the  project.  The  methods  used  to  estimate  the  cost  of  the  project  during  the  selec¬ 
tion  phase  are  generally  faster  and  consume  fewer  resources  than  those  used  to  create  detailed  estimates  in  later 
phases.  They  rely  more  on  the  expert  judgment  of  experienced  managers  who  can  make  accurate  estimates  with 
less  detailed  information.  Estimates  in  the  earliest  stages  of  project  selection  are  usually  based  on  information 
from  previous  projects  that  can  be  adjusted — scaled — to  match  the  size  and  complexity  of  the  current  project  or 
developed  using  standardized  formulas. 

Analogous  Estimate 

An  estimate  that  is  based  on  other  project  estimates  is  an  analogous  estimate.  If  a  similar  project  cost  a  certain 
amount,  then  it  is  reasonable  to  assume  that  the  current  project  will  cost  about  the  same.  Few  projects  are  exactly 
the  same  size  and  complexity,  so  the  estimate  must  be  adjusted  upward  or  downward  to  account  for  the  differ¬ 
ences.  The  selection  of  projects  that  are  similar  and  the  amount  of  adjustment  needed  is  up  to  the  judgment  of  the 
person  who  makes  the  estimate.  Normally,  this  judgment  is  based  on  many  years  of  experience  estimating  pro¬ 
jects,  including  incorrect  estimates  that  were  learning  experiences  for  the  expert. 

Less-experienced  managers  who  are  required  to  make  analogous  estimates  can  look  through  the  documentation 
that  is  available  from  previous  projects.  If  projects  were  evaluated  using  the  Darnall-Preston  Complexity  Index 
(DPCI),  the  manager  can  quickly  identify  projects  that  have  profiles  similar  to  the  project  under  consideration, 
even  if  those  projects  were  managed  by  other  people. 

The  DPCI  assesses  project  attributes,  enabling  better-informed  decisions  in  creating  the  project  profile.  This  index 
assesses  the  complexity  level  of  key  components  of  a  project  and  produces  a  unique  project  profile.  The  profile 
indicates  the  project  complexity  level,  which  provides  a  benchmark  for  comparing  projects  and  information  about 
the  characteristics  of  a  project  that  can  then  be  addressed  in  the  project  execution  plan.  It  achieves  this  objective  by 
grouping  11  attributes  into  four  broad  categories:  internal,  external,  technological  complexity,  and  environmental. 

Comparing  the  original  estimates  with  the  final  project  costs  on  several  previous  projects  with  the  same  DPCI  rat¬ 
ings  gives  a  less-experienced  manager  the  perspective  that  it  would  take  many  years  to  acquire  by  trial  and  error. 
It  also  provides  references  the  manager  can  use  to  justify  the  estimate. 

Example:  Analogous  Estimate  for  John's  Move 

John  sold  his  apartment  and  purchased  another  one.  It  is  now  time  to  plan  for  the  move.  John  asked  a  friend  for 
advice  about  the  cost  of  his  move.  His  friend  replied,  “I  moved  from  an  apartment  a  little  smaller  than  yours  last 
year  and  the  distance  was  about  the  same.  I  did  it  with  a  14-foot  truck.  It  cost  about  $575  for  the  truck  rental,  pads, 
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hand  truck,  rope,  boxes,  and  gas.”  Because  of  the  similarity  of  the  projects,  John’s  initial  estimate  of  the  cost  of 
the  move  was  less  than  $700  so  he  decided  that  the  cost  would  be  affordable  and  the  project  could  go  forward. 

Parametric  Estimate 

If  the  project  consists  of  activities  that  are  common  to  many  other  projects,  average  costs  are  available  per  unit. 
For  example,  if  you  ask  a  construction  company  how  much  it  would  cost  to  build  a  standard  office  building,  the 
estimator  will  ask  for  the  size  of  the  building  in  square  feet  and  the  city  in  which  the  building  will  be  built.  From 
these  two  factors — size  and  location — the  company’s  estimator  can  predict  the  cost  of  the  building.  Factors  like 
size  and  location  are  parameters — measurable  factors  that  can  be  used  in  an  equation  to  calculate  a  result.  The 
estimator  knows  the  average  cost  per  square  foot  of  a  typical  office  building  and  adjustments  for  local  labor  costs. 
Other  parameters  such  as  quality  of  finishes  are  used  to  further  refine  the  estimate.  Estimates  that  are  calculated 
by  multiplying  measured  parameters  by  cost-per-unit  values  are  parametric  estimates. 

Example:  Parametric  Estimate  for  John's  Move 

To  estimate  the  size  of  the  truck  needed  for  John’s  move,  the  parameter  used  by  a  truck  rental  company  is  the 
number  of  bedrooms  (Figure  12.  J).  The  company  assumes  that  the  number  of  bedrooms  is  the  important  parame¬ 
ter  in  determining  how  big  a  truck  is  needed  for  a  move.  John  has  a  one-bedroom  apartment,  so  he  chooses  the 
14-foot  truck.  Once  the  size  is  determined,  other  parameters,  such  as  distance  and  days,  are  used  to  estimate  the 
cost  of  the  truck  rental. 
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Figure  12.1  Parametric  Cost  Estimate 
Source:  http://pm4id.Org/9/l/ 


Bottom-Up  Estimating 

The  most  accurate  and  time-consuming  estimating  method  is  to  identify  the  cost  of  each  item  in  each  activity  of 
the  schedule,  including  labor  and  materials.  If  you  view  the  project  schedule  as  a  hierarchy  where  the  general 
descriptions  of  tasks  are  at  the  top  and  the  lower  levels  become  more  detailed,  finding  the  price  of  each  item  at  the 
lowest  level  and  then  summing  them  to  determine  the  cost  of  higher  levels  is  called  bottom-up  estimating. 

Example:  Bottom-Up  Estimate  for  John's  Move 


Figure  12.2  Detailed  Cost  Estimate 
Source:  http://pm4id.Org/9/l/ 
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After  evaluating  the  bids  by  the  moving  companies,  John  decides  the  savings  are  worth  his  time  if  he  can  get  the 
packing  done  with  the  help  of  his  friends.  He  decides  to  prepare  a  detailed  estimate  of  costs  (Figure  12.2)  for 
packing  materials  and  use  of  a  rental  truck.  He  looks  up  the  prices  for  packing  materials  and  truck  rental  costs  on 
company  websites  and  prepares  a  detailed  list  of  items,  quantities,  and  costs. 

This  type  of  estimate  is  typically  more  accurate  than  an  analogous  or  parametric  estimate.  In  this  example,  the 
sum  of  packing  materials  and  truck  expenses  is  estimated  to  be  $661.25. 

The  estimate  can  be  rolled  up — subtotaled — to  display  less  detail.  This  process  is  made  easier  using  computer 
software.  On  projects  with  low  complexity,  the  cost  estimates  can  be  done  on  spreadsheet  software.  On  larger 
projects,  software  that  manages  schedules  can  also  manage  costs  and  display  them  by  activity  and  category.  For 
example,  the  subtotal  feature  could  be  used  in  Excel  and  collapsed  to  show  the  subtotals  for  the  two  categories  of 
costs  (Figure  12.3). 


Figure  12.3  Sum  of  Detailed  Costs  by  Type 
Source:  http://pm4id.Org/9/l/ 


Activity-Based  Estimates 

An  activity  can  have  costs  from  multiple  vendors  in  addition  to  internal  costs  for  labor  and  materials.  Detailed 
estimates  from  all  sources  can  be  reorganized  so  those  costs  associated  with  a  particular  activity  can  be  grouped 
by  adding  the  activity  code  to  the  detailed  estimate  (Figure  12.4). 


Figure  12.4  Detailed  Costs  Associated  with  Activities 
Source  :  http://pm4id.Org/9/l/ 


The  detailed  cost  estimates  can  be  sorted  and  then  subtotaled  by  activity  to  determine  the  cost  for  each  activity. 
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Managing  the  Budget 

Projects  seldom  go  according  to  plan  in  every  detail.  It  is  necessary  for  the  project  manager  to  be  able  to  identify 
when  costs  are  varying  from  the  budget  and  manage  those  variations. 

Managing  Cash  Flow 

If  the  total  amount  spent  on  a  project  is  equal  to  or  less  than  the  amount  budgeted,  the  project  can  still  be  in  trouble 
if  the  funding  for  the  project  is  not  available  when  it  is  needed.  There  is  a  natural  tension  between  the  financial 
people  in  an  organization,  who  do  not  want  to  pay  for  the  use  of  money  that  is  just  sitting  in  a  checking  account, 
and  the  project  manager,  who  wants  to  be  sure  that  there  is  enough  money  available  to  pay  for  project  expenses. 
The  financial  people  prefer  to  keep  the  company’s  money  working  in  other  investments  until  the  last  moment 
before  transferring  it  to  the  project  account.  The  contractors  and  vendors  have  similar  concerns,  and  they  want  to 
get  paid  as  soon  as  possible  so  they  can  put  the  money  to  work  in  their  own  organizations.  The  project  manager 
would  like  to  have  as  much  cash  available  as  possible  to  use  if  activities  exceed  budget  expectations. 

Contingency  Reserves 

Most  projects  have  something  unexpected  occur  that  increases  costs  above  the  original  estimates.  If  estimates  are 
rarely  exceeded,  the  estimating  method  should  be  reviewed  because  the  estimates  are  too  high.  It  is  impossible  to 
predict  which  activities  will  cost  more  than  expected,  but  it  is  reasonable  to  assume  that  some  of  them  will.  Esti¬ 
mating  the  likelihood  of  such  events  is  part  of  risk  analysis,  which  is  discussed  in  more  detail  in  a  later  chapter. 

Instead  of  overestimating  each  cost,  money  is  budgeted  for  dealing  with  unplanned  but  statistically  predictable 
cost  increases.  Funds  allocated  for  this  purpose  are  called  contingency  reserves.  Because  it  is  likely  that  this 
money  will  be  spent,  it  is  part  of  the  total  budget  for  the  project.  If  this  fund  is  adequate  to  meet  the  unplanned 
expenses,  then  the  project  will  complete  within  the  budget. 

Management  Reserves 

If  something  occurs  during  the  project  that  requires  a  change  in  the  project  scope,  money  may  be  needed  to  deal 
with  the  situation  before  a  change  in  scope  can  be  negotiated  with  the  project  sponsor  or  client.  It  could  be  an 
opportunity  as  well  as  a  challenge.  For  example,  if  a  new  technology  were  invented  that  would  greatly  enhance 
your  completed  project,  there  would  be  additional  cost  and  a  change  to  the  scope,  but  it  would  be  worth  it.  Money 
can  be  made  available  at  the  manager’s  discretion  to  meet  needs  that  would  change  the  scope  of  the  project.  These 
funds  are  called  management  reserves.  Unlike  contingency  reserves,  they  are  not  likely  to  be  spent  and  are  not 
part  of  the  project’s  budget  baseline,  but  they  can  be  included  in  the  total  project  budget. 

Evaluating  the  Budget  During  the  Project 

A  project  manager  must  regularly  compare  the  amount  of  money  spent  with  the  budgeted  amount  and  report  this 
information  to  managers  and  stakeholders.  It  is  necessary  to  establish  an  understanding  of  how  this  progress  will 
be  measured  and  reported. 
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Example:  Reporting  Budget  Progress  on  John's  Move 

In  the  John’s  move  example,  he  estimated  that  the  move  would  cost  about  $1,500  and  take  about  16  days.  Eight 
days  into  the  project,  John  has  spent  $300.  John  tells  his  friends  that  the  project  is  going  well  because  he  is  halfway 
through  the  project  but  has  only  spent  a  fifth  of  his  budget.  John’s  friend  Carlita  points  out  that  his  report  is  not 
sufficient  because  he  did  not  compare  the  amount  spent  to  the  budgeted  amount  for  the  activities  that  should  be 
done  by  the  eighth  day. 

As  John’s  friend  pointed  out,  a  budget  report  must  compare  the  amount  spent  with  the  amount  that  is  expected 
to  be  spent  by  that  point  in  the  project.  Basic  measures  such  as  percentage  of  activities  completed,  percentage  of 
measurement  units  completed,  and  percentage  of  budget  spent  are  adequate  for  less  complex  projects,  but  more 
sophisticated  techniques  are  used  for  projects  with  higher  complexity. 

Earned  Value  Analysis 

A  method  that  is  widely  used  for  medium-  and  high-complexity  projects  is  the  earned  value  management 
(EVM)  method.  EVM  is  a  method  of  periodically  comparing  the  budgeted  costs  with  the  actual  costs  during  the 
project.  It  combines  the  scheduled  activities  with  detailed  cost  estimates  of  each  activity.  It  allows  for  partial  com¬ 
pletion  of  an  activity  if  some  of  the  detailed  costs  associated  with  the  activity  have  been  paid  but  others  have  not. 

The  budgeted  cost  of  work  scheduled  (BCWS)  comprises  the  detailed  cost  estimates  for  each  activity  in  the  pro¬ 
ject.  The  amount  of  work  that  should  have  been  done  by  a  particular  date  is  the  planned  value  (PV).  These  terms 
are  used  interchangeably  by  some  sources,  but  the  planned  value  term  is  used  in  formulas  to  refer  to  the  sum  of 
the  budgeted  cost  of  work  up  to  a  particular  point  in  the  project,  so  we  will  make  that  distinction  in  the  definitions 
in  this  text  for  clarity. 

Example:  Planned  Value  on  Day  Six  of  John's  Move 

On  day  six  of  the  project,  John  should  have  taken  his  friends  to  lunch  and  purchased  the  packing  materials.  The 
portion  of  the  BCWS  that  should  have  been  done  by  that  date  (the  planned  value)  is  shown  in  Figure  12.5.  This  is 
the  planned  value  for  day  six  of  the  project. 


Figure  12.5  Planned  Value  for  Lunch 
and  Packing  Materials 
Source:  http://pm4id.Org/9/2/ 


The  budgeted  cost  of  work  performed  (BCWP)  is  the  budgeted  cost  of  work  scheduled  that  has  been  done.  If 
you  sum  the  BCWP  values  up  to  that  point  in  the  project  schedule,  you  have  the  earned  value  (EV).  The  amount 
spent  on  an  item  is  often  more  or  less  than  the  estimated  amount  that  was  budgeted  for  that  item.  The  actual  cost 
(AC)  is  the  sum  of  the  amounts  actually  spent  on  the  items. 
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Example:  Comparing  PV,  EV,  and  AC  in  John's  Move  on  Day  Six 

Dion  and  Carlita  were  both  trying  to  lose  weight  and  just  wanted  a  nice  salad.  Consequendy,  the  lunch  cost  less 
than  expected.  John  makes  a  stop  at  a  store  that  sells  moving  supplies  at  discount  rates.  They  do  not  have  all  the 
items  he  needs,  but  the  prices  are  lower  than  those  quoted  by  the  moving  company.  They  have  a  very  good  price 
on  lifting  straps  so  he  decides  to  buy  an  extra  pair.  He  returns  with  some  of  the  items  on  his  list,  but  this  phase  of 
the  job  is  not  complete  by  the  end  of  day  six.  John  bought  half  of  the  small  boxes,  all  of  five  other  items,  twice 
as  many  lifting  straps,  and  none  of  four  other  items.  John  is  only  six  days  into  his  project,  and  his  costs  and  per¬ 
formance  are  starting  to  vary  from  the  plan.  Earned  value  analysis  gives  us  a  method  for  reporting  that  progress 
(Figure  12.6). 


Figure  12.6  Planned  Value,  Earned  Value,  and  Actual  Cost 
Source:  http://pm4id.Org/9/2/ 


The  original  schedule  called  for  spending  $261.65  (PV)  by  day  six.  The  amount  of  work  done  was  worth  $162.10 
(EV)  according  to  the  estimates,  but  the  actual  cost  was  only  $154.50  (AC). 

Schedule  Variance 

The  project  manager  must  know  if  the  project  is  on  schedule  and  within  the  budget.  The  difference  between 
planned  and  actual  progress  is  the  variance.  The  schedule  variance  (SV)  is  the  difference  between  the  earned 
value  (EV)  and  the  planned  value  (PV).  Expressed  as  a  formula,  SV  =  EV  -  PV.  If  less  value  has  been  earned  than 
was  planned,  the  schedule  variance  is  negative,  which  means  the  project  is  behind  schedule. 

Example:  Schedule  Variance  on  John's  Move 

Planning  for  John’s  move  calls  for  spending  $261.65  by  day  six,  which  is  the  planned  value  (PV).  The  difference 
between  the  planned  value  and  the  earned  value  is  the  scheduled  variance  (SV).  The  formula  is  SV  =  EV  -  PV.  In 
this  example,  SV  =  $162.10  -  $261.65  =  ($99.55)  A  negative  SV  indicates  the  project  is  behind  schedule. 

The  difference  between  the  earned  value  (EV)  and  the  actual  cost  (AC)  is  the  cost  variance  (CV).  Expressed  as  a 
formula,  CV  =  EV  -  AC.  A  positive  CV  indicates  the  project  is  under  budget. 

Example:  Cost  Variance  on  John's  Move 

The  difference  between  the  earned  value  of  $162.10  and  the  actual  cost  of  $154.50  is  the  cost  variance  (CV).  The 
formula  is  CV  =  EV  -  AC.  In  this  example,  CV  =  $162.10  -  $154.50  =  $7.60. 


Variance  Indexes  for  Schedule  and  Cost 
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The  schedule  variance  and  the  cost  variance  provide  the  amount  by  which  the  spending  is  behind  (or  ahead  of) 
schedule  and  the  amount  by  which  a  project  is  exceeding  (or  not  fully  using)  its  budget.  They  do  not  give  an  idea 
of  how  these  amounts  compare  with  the  total  budget. 

The  ratio  of  earned  value  to  planned  value  gives  an  indication  of  how  much  of  the  project  is  completed.  This  ratio 
is  the  schedule  performance  index  (SPI).  The  formula  is  SP1  =  EV/PV.  In  the  John’s  move  example,  the  SP1 
equals  0.62  (SPI  =  $162.10/$261.65  =  0.62)  An  SPI  value  less  than  1  indicates  the  project  is  behind  schedule. 

The  ratio  of  the  earned  value  to  the  actual  cost  is  the  cost  performance  index  (CPI).  The  formula  is  CPI  =  EV/ 
AC. 


Example:  Cost  Performance  Index  of  John's  Move 

In  the  John’s  move  example,  CPI  =  $162.10/$154.50  =  1.05.  A  value  greater  than  1  indicates  that  the  project  is 
under  budget. 


Figure  12.7  Schedule  Variance  and  Cost  Variance 
Source:  http://pm4id.Org/9/2/ 


The  cost  variance  of  positive  $7.60  and  the  CPI  value  of  1.05  tell  John  that  he  is  getting  more  value  for  his  money 
than  planned  for  the  tasks  scheduled  by  day  six.  The  schedule  variance  (SV)  of  negative  $99.55  and  the  schedule 
performance  index  (SPI)  of  0.62  tell  him  that  he  is  behind  schedule  in  adding  value  to  the  project  (Figure  12.7). 

During  the  project,  the  manager  can  evaluate  the  schedule  using  the  schedule  variance  ($V)  and  the  schedule  per¬ 
formance  index  (SPI),  and  the  budget  using  the  cost  variance  (CV)  and  the  cost  performance  index  (CPI). 

Estimated  Cost  to  Complete  the  Project 

Part  way  through  the  project,  the  manager  evaluates  the  accuracy  of  the  cost  estimates  for  the  activities  that  have 
taken  place  and  uses  that  experience  to  predict  how  much  money  it  will  take  to  complete  the  unfinished  activi¬ 
ties — the  estimate  to  complete  (ETC). 

To  calculate  the  ETC,  the  manager  must  decide  if  the  cost  variance  observed  in  the  estimates  to  that  point  are 
representative  of  the  future.  For  example,  if  unusually  bad  weather  causes  increased  cost  during  the  first  part  of 
the  project,  it  is  not  likely  to  have  the  same  effect  on  the  rest  of  the  project.  If  the  manager  decides  that  the  cost 
variance  up  to  this  point  in  the  project  is  atypical — not  typical — then  the  estimate  to  complete  is  the  difference 
between  the  original  budget  for  the  entire  project — the  budget  at  completion  (BAC) — and  the  earned  value  (EV) 
up  to  that  point.  Expressed  as  a  formula,  ETC  =  BAC  -  EV. 

Example:  Estimate  to  Complete  John's  Move 

For  his  move,  John  was  able  to  buy  most  of  the  items  at  a  discount  house  that  did  not  have  a  complete  inventory, 
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and  he  chose  to  buy  an  extra  pair  of  lift  straps.  He  knows  that  the  planned  values  for  packing  materials  were 
obtained  from  the  price  list  at  the  moving  company  where  he  will  have  to  buy  the  rest  of  the  items,  so  those  two 
factors  are  not  likely  to  be  typical  of  the  remaining  purchases.  The  reduced  cost  of  lunch  is  unrelated  to  the  future 
costs  of  packing  materials,  truck  rentals,  and  hotel  fees.  John  decides  that  the  factors  that  caused  the  variances 
are  atypical.  He  calculates  that  the  estimate  to  complete  (ETC)  is  the  budget  at  completion  ($1,534)  minus  the 
earned  value  at  that  point  ($162.10),  which  equals  $1,371.90.  Expressed  as  a  formula,  ETC  =  $1,534  -  $162.10  = 
$1,371.90. 

If  the  manager  decides  that  the  cost  variance  is  caused  by  factors  that  will  affect  the  remaining  activities,  such  as 
higher  labor  and  material  costs,  then  the  estimate  to  complete  (ETC)  needs  to  be  adjusted  by  dividing  it  by  the 
cost  performance  index  (CPI).  For  example,  if  labor  costs  on  the  first  part  of  a  project  are  estimated  at  $80,000 
(EV)  and  they  actually  cost  $85,000  (AC),  the  cost  performance  (CPI)  will  be  0.94.  (Recall  that  the  CPI  =  EV/ 
AC.) 

To  calculate  the  estimate  to  complete  (ETC),  assuming  the  cost  variance  on  known  activities  is  typical  of  future 
cost,  the  formula  is  ETC  =  (BAC  -  EV)/CPI.  If  the  budget  at  completion  (BAC)  of  the  project  is  $800,000,  the 
estimate  to  complete  is  ($800,000  -  $80,000)/0.94  =  $766,000. 

Estimate  Final  Project  Cost 

If  the  costs  of  the  activities  up  to  the  present  vary  from  the  original  estimates,  this  will  affect  the  total  estimate 
of  the  project  cost.  The  new  estimate  of  the  project  cost  is  the  estimate  at  completion  (EAC).  To  calculate  the  EAC, 
the  estimate  to  complete  (ETC)  is  added  to  the  actual  cost  (AC)  of  the  activities  already  performed.  Expressed 
as  a  formula,  EAC  =  AC  +  ETC. 

Example:  Estimate  at  Completion  for  John's  Move 

The  revised  estimate  at  completion  (EAC)  for  John’s  move  at  this  point  in  the  process  is  EAC  =  $154.50  + 
$1,371.90  =  $1,526.40. 


Figure  12.8  Summary  of  Terms  and  Formulas  for  Earned  Value 
Analysis 

Source:  http://pm4id.Org/9/2/ 


To  summarize  (Figure  12.8): 

•  Extra  money  is  allocated  in  a  contingency  fund  to  deal  with  activities  where  costs  exceed  estimates.  Funds 
are  allocated  in  a  management  reserve  in  case  a  significant  opportunity  or  challenge  occurs  that  requires 
change  of  scope  but  funds  are  needed  immediately  before  a  scope  change  can  typically  be  negotiated. 


•  Schedule  variance  is  the  difference  between  the  part  of  the  budget  that  has  been  spent  so  far  (EV)  versus  the 
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part  that  was  planned  to  be  spent  by  now  (PV).  Similarly,  the  cost  variance  is  the  difference  between  the  EV 
and  the  actual  cost  (AC). 

•  The  schedule  performance  index  (SP1)  is  the  ratio  of  the  earned  value  and  the  planned  value.  The  cost  per¬ 
formance  index  (CPI)  is  the  ratio  of  the  earned  value  (EV)  to  the  actual  cost  (AC). 

•  The  formula  used  to  calculate  the  amount  of  money  needed  to  complete  the  project  (ETC)  depends  on 
whether  or  not  the  cost  variance  to  this  point  is  expected  to  continue  (typical)  or  not  (atypical).  If  the  cost 
variance  is  atypical,  the  ETC  is  simply  the  original  total  budget  (BAC)  minus  the  earned  value  (EV).  If  they 
are  typical  of  future  cost  variances,  the  ETC  is  adjusted  by  dividing  the  difference  between  BAC  and  EV  by 
the  CPI. 

•  The  final  budget  is  the  actual  cost  (AC)  to  this  point  plus  the  estimate  to  complete  (ETC). 


Establishing  a  Budget 

Once  you  have  broken  your  project  down  into  activities,  you  will  be  able  to  calculate  your  overall  project  costs  by 
estimating  and  totaling  the  individual  activity  costs. 

This  process  of  subtotaling  costs  by  category  or  activity  is  called  cost  aggregation. 

Budget  Timeline 

Costs  are  associated  with  activities,  and  since  each  activity  has  a  start  date  and  a  duration  period,  it  is  possible  to 
calculate  how  much  money  will  be  spent  by  any  particular  date  during  the  project.  The  money  needed  to  pay  for 
a  project  is  usually  transferred  to  the  project  account  shortly  before  it  is  needed.  These  transfers  must  be  timed  so 
that  the  money  is  there  to  pay  for  each  activity  without  causing  a  delay  in  the  start  of  the  activity.  If  the  money  is 
transferred  too  far  in  advance,  the  organization  will  lose  the  opportunity  to  use  the  money  somewhere  else,  or  they 
will  have  to  pay  unnecessary  interest  charges  if  the  money  is  borrowed.  A  schedule  of  money  transfers  is  created 
that  should  match  the  need  to  pay  for  the  activities.  The  process  of  matching  the  schedule  of  transfers  with  the 
schedule  of  activity  payments  is  called  reconciliation.  Refer  to  Figure  12.9,  which  shows  the  costs  of  10  major 
activities  in  a  project.  Funds  are  transferred  into  the  project  account  four  times.  Notice  that  during  most  of  the 
project,  there  were  more  funds  available  than  were  spent  except  at  activity  6  when  all  the  available  funds  were 
spent. 


Figure  12.9  Fund  Transfers  and  Expenditures 
Source:  http://pm4id.Org/9/l/ 
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In  the  project  budget  profile  shown  in  Figure  12.9,  there  is  no  margin  for  error  if  the  total  of  the  first  six  activities 
exceeds  the  amount  of  funding  at  that  point  in  the  project. 

Contractual  agreements  with  vendors  often  require  partial  payment  of  their  costs  during  the  project.  Those  con¬ 
tracts  can  be  managed  more  conveniently  if  the  unit  of  measure  for  partial  completion  is  the  same  as  that  used 
for  cost  budgeting.  For  example,  if  a  graphic  designer  is  putting  together  several  pieces  of  artwork  for  a  textbook, 
their  contract  may  call  for  partial  payment  after  25%  of  their  total  number  of  drawings  is  complete. 
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13.  Procurement  Management 


ADRIENNE  WATT 


Procurement  management  follows  a  logical  order.  First,  you  plan  what  you  need  to  contract;  then  you  plan  how 
you’ll  do  it.  Next,  you  send  out  your  contract  requirements  to  sellers.  They  bid  for  the  chance  to  work  with  you. 
You  pick  the  best  one,  and  then  you  sign  the  contract  with  them.  Once  the  work  begins,  you  monitor  it  to  make 
sure  that  the  contract  is  being  followed.  When  the  work  is  done,  you  close  out  the  contract  and  fill  out  all  the 
paperwork. 

You  need  to  start  with  a  plan  for  the  whole  project.  Before  doing  anything  else,  you  need  to  think  about  all  of  the 
work  that  you  will  contract  out  for  your  project.  You  will  want  to  plan  for  any  purchases  and  acquisitions.  Here’s 
where  you  take  a  close  look  at  your  needs  to  be  sure  that  contracting  is  necessary.  You  figure  out  what  kinds  of 
contracts  make  sense  for  your  project,  and  you  try  to  define  all  of  the  parts  of  the  project  that  will  be  contracted 
out. 

Contract  planning  is  where  you  plan  out  each  individual  contract  for  the  project  work.  You  work  out  how 
you’ll  manage  the  contract,  what  metrics  it  will  need  to  meet  to  be  considered  successful,  how  you’ll  pick  a  seller, 
and  how  you’ll  administer  the  contract  once  the  work  is  happening. 

The  procurement  management  plan  details  how  the  procurement  process  will  be  managed.  It  includes  the  follow¬ 
ing  information: 

•  The  types  of  contracts  you  plan  to  use  and  any  metrics  that  will  be  used  to  measure  the  contractors’  perfor¬ 
mance 

•  The  planned  delivery  dates  for  the  work  or  products  you  are  contracting 

•  The  company’s  standard  documents  you  will  use 

•  The  number  of  vendors  or  contractors  involved  and  how  they  will  be  managed 

•  How  purchasing  may  impact  the  constraints  and  assumptions  of  the  project  plan 

•  The  coordination  of  purchasing  lead  times  with  the  development  of  the  project  schedule 

•  The  identification  of  prequalified  sellers  (if  known) 
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The  procurement  management  plan,  like  all  other  management  plans,  becomes  a  subsidiary  of  the  project  manage¬ 
ment  plan.  Some  tools  and  techniques  you  may  use  during  the  procurement  planning  stage  include  make-or-buy 
analysis  and  definition  of  the  contract  type. 


Make-or-Buy  Analysis 

This  means  figuring  out  whether  or  not  you  should  be  contracting  the  work  or  doing  it  yourself,  ft  could  also  mean 
deciding  whether  to  build  a  solution  to  your  problem  or  buy  one  that  is  already  available.  Most  of  the  same  factors 
that  help  you  make  every  other  major  project  decision  will  help  you  with  this  one.  How  much  does  it  cost  to  build 
it  as  opposed  to  buying  it?  How  will  this  decision  affect  the  scope  of  your  project?  How  will  it  affect  the  project 
schedule?  Do  you  have  time  to  do  the  work  and  still  meet  your  commitments?  As  you  plan  out  what  you  will  and 
won’t  contract,  you  need  to  think  through  your  reasoning  very  carefully. 

There  are  some  resources  (like  heavy  equipment)  that  your  company  can  buy,  rent,  or  lease  depending  on  the  sit¬ 
uation.  You’ll  need  to  examine  leasing-versus-buying  costs  and  determine  the  best  way  to  go  forward. 


Contract  Types 

You  should  know  a  little  bit  about  the  major  kinds  of  contracts  available  to  you  (the  client)  so  that  you  choose 
the  one  that  creates  the  most  fair  and  workable  deal  for  you  and  the  contractor.  Some  contracts  are  fixed  price:  no 
matter  how  much  time  or  effort  goes  into  them,  the  client  always  pay  the  same.  In  Figure  13.1  the  cost  to  the  client 
stays  the  same,  but  as  more  effort  is  exerted  the  profit  to  the  contractor  goes  down.  Some  are  cost  reimbursable 
also  called  cost  plus.  This  is  where  the  seller  charges  you  for  the  cost  of  doing  the  work  plus  some  fee  or  rate. 
Figure  13.2  illustrates  this  by  showing  that  as  efforts  increase,  costs  to  the  client  go  up  but  the  contractor’s  profits 
stay  the  same.  The  third  major  kind  of  contract  is  time  and  materials.  That’s  where  the  client  pays  a  rate  for  the 
time  spent  working  on  the  project  and  also  pays  for  all  the  materials  used  to  do  the  work.  Figure  13.3  shows  that 
as  costs  to  the  client  go  up,  so  does  the  profit  for  the  contractor. 

Fixed-Price  Contracts 

The  fixed-price  contract  is  a  legal  agreement  between  the  project  organization  and  an  entity  (person  or  company) 
to  provide  goods  or  services  to  the  project  at  an  agreed-on  price.  The  contract  usually  details  the  quality  of  the 
goods  or  services,  the  timing  needed  to  support  the  project,  and  the  price  for  delivering  goods  or  services.  There 
are  several  variations  of  the  fixed-price  contract.  For  commodities  and  goods  and  services  where  the  scope  of 
work  is  very  clear  and  not  likely  to  change,  the  fixed-price  contract  offers  a  predictable  cost.  The  responsibil¬ 
ity  for  managing  the  work  to  meet  the  needs  of  the  project  is  focused  on  the  contractor.  The  project  team  tracks 
the  quality  and  schedule  progress  to  ensure  the  contractors  will  meet  the  project  needs.  The  risks  associated  with 
fixed-price  contracts  are  the  costs  associated  with  project  change.  If  a  change  occurs  on  the  project  that  requires  a 
change  order  from  the  contractor,  the  price  of  the  change  is  typically  very  high.  Even  when  the  price  for  changes 
is  included  in  the  original  contract,  changes  on  a  fixed-price  contract  will  create  higher  total  project  costs  than 
other  forms  of  contracts  because  the  majority  of  the  cost  risk  is  transferred  to  the  contractor,  and  most  contractors 
will  add  a  contingency  to  the  contract  to  cover  their  additional  risk. 
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Cost  (revenue) 


Effort 


Figure  13.1:  A  fixed-price  contract  the  cost  to  the  client  is 
constant  regardless  of  effort  applied  or  delivery  date. 
Illustration  from  Barron  &  Barron  Project  Management  for 
Scientists  and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


Fixed-price  contracts  require  the  availability  of  at  least  two  or  more  suppliers  that  have  the  qualifications  and  per¬ 
formance  histories  that  ensure  the  needs  of  the  project  can  be  met.  The  other  requirement  is  a  scope  of  work  that 
is  most  likely  not  going  to  change.  Developing  a  clear  scope  of  work  based  on  good  information,  creating  a  list  of 
highly  qualified  bidders,  and  developing  a  clear  contract  that  reflects  that  scope  of  work  are  critical  aspects  of  a 
good  fixed-priced  contract. 

If  the  service  provider  is  responsible  for  incorporating  all  costs,  including  profit,  into  the  agreed-on  price,  it  is  a 
fixed-total-cost  contract.  The  contractor  assumes  the  risks  for  unexpected  increases  in  labor  and  materials  that 
are  needed  to  provide  the  service  or  materials  and  in  the  materials  and  timeliness  needed. 

The  fixed-price  contract  with  price  adjustment  is  used  for  unusually  long  projects  that  span  years.  The  most 
common  use  of  this  type  of  contract  is  the  inflation-adjusted  price.  In  some  countries,  the  value  of  its  local  cur¬ 
rency  can  vary  greatly  in  a  few  months,  which  affects  the  cost  of  local  materials  and  labor.  In  periods  of  high 
inflation,  the  client  assumes  the  risk  of  higher  costs  due  to  inflation,  and  the  contract  price  is  adjusted  based  on  an 
inflation  index.  The  volatility  of  certain  commodities  can  also  be  accounted  for  in  a  price-adjustment  contract.  For 
example,  if  the  price  of  oil  significantly  affects  the  costs  of  the  project,  the  client  can  accept  the  oil  price  volatility 
risk  and  include  a  provision  in  the  contract  that  would  allow  the  contract  price  adjustment  based  on  a  change  in 
the  price  of  oil. 

The  fixed-price  contract  with  incentive  fee  provides  an  incentive  for  performing  on  the  project  above  the  estab¬ 
lished  baseline  in  the  contract.  The  contract  might  include  an  incentive  for  completing  the  work  on  an  important 
milestone  for  the  project.  Often  contracts  have  a  penalty  clause  if  the  work  is  not  performed  according  to  the  con¬ 
tract.  For  example,  if  the  new  software  is  not  completed  in  time  to  support  the  implementation  of  the  training,  the 
contract  might  penalize  the  software  company  a  daily  amount  of  money  for  every  day  the  software  is  late.  This 
type  of  penalty  is  often  used  when  the  software  is  critical  to  the  project  and  the  delay  will  cost  the  project  signifi¬ 
cant  money. 

If  the  service  or  materials  can  be  measured  in  standard  units,  but  the  amount  needed  is  not  known  accurately,  the 
price  per  unit  can  be  fixed — a  fixed-unit-price  contract.  The  project  team  assumes  the  responsibility  of  estimat¬ 
ing  the  number  of  units  used.  If  the  estimate  is  not  accurate,  the  contract  does  not  need  to  be  changed,  but  the 
project  will  exceed  the  budgeted  cost. 
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Figure  13.2  Table  of  Fixed  Price  Contracts  and  Characteristics 
Source:  http://pm4id.Org/9/5/ 


Cost-Reimbursable  Contracts 

In  a  cost-reimbursable  contract,  the  organization  agrees  to  pay  the  contractor  for  the  cost  of  performing  the 
service  or  providing  the  goods.  Cost-reimbursable  contracts  are  also  known  as  cost-plus  contracts.  Cost-reim¬ 
bursable  contracts  are  most  often  used  when  the  scope  of  work  or  the  costs  for  performing  the  work  are  not  well 
known.  The  project  uses  a  cost-reimbursable  contract  to  pay  the  contractor  for  allowable  expenses  related  to  per¬ 
forming  the  work.  Since  the  cost  of  the  project  is  reimbursable,  the  contractor  has  much  less  risk  associated  with 
cost  increases.  When  the  costs  of  the  work  are  not  well  known,  a  cost-reimbursable  contract  reduces  the  amount  of 
money  the  bidders  place  in  the  bid  to  account  for  the  risk  associated  with  potential  increases  in  costs.  The  contrac¬ 
tor  is  also  less  motivated  to  find  ways  to  reduce  the  cost  of  the  project  unless  there  are  incentives  for  supporting 
the  accomplishment  of  project  goals. 
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Figure  13.3:  In  a  cost-reimbursable  or  cost-plus  contract,  the 
contractor  is  guaranteed  a  fee,  but  the  client’s  costs  can  increase 
based  on  effort. 

Illustration  from  Barron  &  Barron  Project  Management  for 
Scientists  and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


Cost-reimbursable  contracts  require  good  documentation  of  the  costs  that  occurred  on  the  project  to  ensure  that 
the  contractor  gets  paid  for  all  the  work  performed  and  to  ensure  that  the  organization  is  not  paying  for  something 
that  was  not  completed.  The  contractor  is  also  paid  an  additional  amount  above  the  costs.  There  are  several  ways 
to  compensate  the  contractor. 

•  A  cost-reimbursable  contract  with  a  fixed  fee  provides  the  contractor  with  a  fee,  or  profit  amount,  that  is 
determined  at  the  beginning  of  the  contract  and  does  not  change. 

•  A  cost-reimbursable  contract  with  a  percentage  fee  pays  the  contractor  for  costs  plus  a  percentage  of  the 
costs,  such  as  5%  of  total  allowable  costs.  The  contractor  is  reimbursed  for  allowable  costs  and  is  paid  a  fee. 

•  A  cost-reimbursable  contract  with  an  incentive  fee  is  used  to  encourage  performance  in  areas  critical  to 
the  project.  Often  the  contract  attempts  to  motivate  contractors  to  save  or  reduce  project  costs.  The  use  of 
the  cost  reimbursable  contract  with  an  incentive  fee  is  one  way  to  motivate  cost-reduction  behaviors. 
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•  A  cost-reimbursable  contract  with  award  fee  reimburses  the  contractor  for  all  allowable  costs  plus  a  fee 
that  is  based  on  performance  criteria.  The  fee  is  typically  based  on  goals  or  objectives  that  are  more  subjec¬ 
tive.  An  amount  of  money  is  set  aside  for  the  contractor  to  earn  through  excellent  performance,  and  the 
decision  on  how  much  to  pay  the  contractor  is  left  to  the  judgment  of  the  project  team.  The  amount  is  suffi¬ 
cient  to  motivate  excellent  performance. 

On  small  activities  that  have  a  high  uncertainty,  the  contractor  might  charge  an  hourly  rate  for  labor,  plus  the  cost 
of  materials,  plus  a  percentage  of  the  total  costs.  This  type  of  contract  is  called  time  and  materials  (T&M).  Time 
is  usually  contracted  on  an  hourly  rate  basis  and  the  contractor  usually  submits  time  sheets  and  receipts  for  items 
purchased  on  the  project.  The  project  reimburses  the  contractor  for  the  time  spent  based  on  the  agreed-on  rate  and 
the  actual  cost  of  the  materials.  The  fee  is  typically  a  percentage  of  the  total  cost. 


Effort 


Figure  13.4:  In  a  time-and-materials  contract  the  profit  to  the 
contractor  increases  with  increased  effort,  as  does  the  costs  to  the 
client. 

Illustration  from  Barron  &  Barron  Project  Management  for 
Scientists  and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


T&M  contracts  are  used  on  projects  for  work  that  is  smaller  in  scope  and  has  uncertainty  or  risk.  The  project, 
rather  than  the  contractor,  assumes  the  risk.  Since  the  contractor  will  most  likely  include  contingency  in  the  price 
of  other  types  of  contracts  to  cover  the  high  risk,  T&M  contracts  provide  lower  total  cost  to  the  project. 


Figure  13.5:  Table  of  cost-reimbursable  contracts 
Source:  http://pm4id.Org/9/5/ 


To  minimize  the  risk  to  the  project,  the  contractor  typically  includes  a  not-to-exceed  amount,  which  means  the 
contract  can  only  charge  up  to  the  agreed  amount.  The  T&M  contract  allows  the  project  to  make  adjustments  as 
more  information  is  available.  The  final  cost  of  the  work  is  not  known  until  sufficient  information  is  available  to 
complete  a  more  accurate  estimate. 
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Progress  Payments  and  Change  Management 

Vendors  and  suppliers  usually  require  payments  during  the  life  of  the  contract.  On  contracts  that  last  several 
months,  the  contractor  will  incur  significant  cost  and  will  want  the  project  to  pay  for  these  costs  as  early  as  possi¬ 
ble.  Rather  than  wait  until  the  end  of  the  contract,  a  schedule  of  payments  is  typically  developed  as  part  of  the  con¬ 
tract  and  is  connected  to  the  completion  of  a  defined  amount  of  work  or  project  milestones.  These  payments  made 
before  the  end  of  the  project  and  based  on  the  progress  of  the  work  are  called  progress  payments.  For  example, 
the  contract  might  develop  a  payment  schedule  that  pays  for  the  design  of  the  curriculum,  then  the  development 
of  the  curriculum,  and  then  a  final  payment  is  made  when  the  curriculum  is  completed  and  accepted.  In  this  case 
there  would  be  three  payments  made.  There  is  a  defined  amount  of  work  to  be  accomplished,  a  time  frame  for 
accomplishing  that  work,  and  a  quality  standard  the  work  must  achieve  before  the  contractor  is  paid  for  the  work. 

Just  as  the  project  has  a  scope  of  work  that  defines  what  is  included  in  the  project  and  what  work  is  outside  the 
project,  vendors  and  suppliers  have  a  scope  of  work  that  defines  what  they  will  produce  or  supply  to  the  company. 
(Partners  typically  share  the  project  scope  of  work  and  may  not  have  a  separate  scope  of  work.)  Often  changes 
occur  on  the  project  that  require  changes  in  the  contractor’s  scope  of  work.  How  these  changes  will  be  managed 
during  the  life  of  the  project  is  typically  documented  in  the  contract.  Capturing  these  changes  early,  documenting 
what  changed  and  how  the  change  impacted  the  contract,  and  developing  a  change  order  (a  change  to  the  contract) 
are  important  to  maintaining  the  progress  of  the  project.  Conflict  among  team  members  may  arise  when  changes 
are  not  documented  or  when  the  team  cannot  agree  on  the  change.  Developing  and  implementing  an  effective 
change  management  process  for  contractors  and  key  suppliers  will  minimize  this  conflict  and  the  potential  nega¬ 
tive  effect  on  the  project. 

Source:  http://pm4id.org/975/ 


Procurement  Process 

The  project  procurement  cycle  reflects  the  procurement  activities  from  the  decision  to  purchase  the  material  or 
service  through  to  the  payment  of  bills  and  closing  of  procurement  contracts. 

Procurement  Plan 

After  the  decision  has  been  made  to  purchase  goods  or  outsource  services,  the  procurement  team  develops  a  plan 
that  includes  the  following: 

•  Selecting  the  appropriate  relationships  and  contract  approaches  for  each  type  of  purchased  goods  or  out¬ 
sourced  service 

•  Preparing  requests  for  quotes  (RFQs)  and  requests  for  proposals  (RFPs)  and  evaluating  partnership  opportu¬ 
nities 

•  Evaluating  RFQs,  RFPs,  and  partnerships 

•  Awarding  and  signing  contracts 

•  Managing  quality  and  timely  performance 


Managing  contract  changes 
Closing  contracts 
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Depending  on  the  complexity  level  of  the  project,  each  of  these  steps  can  take  either  hours  or  sometimes  weeks 
of  work  to  complete.  Each  of  these  steps  is  also  included  in  the  project  master  schedule.  The  time  involved  in 
the  procurement  cycle  can  influence  the  scheduling  of  critical  activities,  including  the  decision  to  self-perform 
the  work  or  contract  the  work  to  others.  The  delivery  dates  for  equipment  and  materials  and  the  work  completion 
dates  for  contracted  works  are  placed  on  the  project  schedule.  Any  procurement  activities  that  create  a  project 
delay  or  fall  on  the  project  critical  path  may  require  special  attention. 

Selecting  the  Contract  Approach 

The  technical  teams  typically  develop  a  description  of  the  work  that  will  be  outsourced.  From  this  information, 
the  project  management  team  answers  the  following  questions: 

•  Is  the  required  work  or  materials  a  commodity,  customized  product  or  service,  or  unique  skill  or  relation¬ 
ship? 

•  What  type  of  relationship  is  needed:  supplier,  vendor,  or  partnership? 

•  How  should  the  supplier,  vendor,  or  potential  partner  be  approached:  RFQ,  RFP,  or  personal  contact? 

•  How  well  known  is  the  scope  of  work? 

•  What  are  the  risks  and  which  party  should  assume  which  types  of  risk? 

•  Does  the  procurement  of  the  service  or  goods  affect  activities  on  the  project  schedule’s  critical  path  and 
how  much  float  is  there  on  those  activities? 

•  How  important  is  it  to  be  sure  of  the  cost  in  advance? 

The  procurement  team  uses  the  answers  to  the  first  three  questions  listed  above  to  determine  the  approach  to 
obtaining  the  goods  or  services  and  the  remaining  questions  to  determine  what  type  of  contract  is  most  appropri¬ 
ate. 

A  key  factor  in  selecting  the  contract  approach  is  determining  which  party  will  take  the  most  risk.  The  team  deter¬ 
mines  the  level  of  risk  that  will  be  managed  by  the  project  and  what  risks  will  be  transferred  to  the  contractor. 
Typically,  the  project  management  team  wants  to  manage  the  project  risk,  but  in  some  cases,  contractors  have 
more  expertise  or  control  that  enable  them  to  better  manage  the  risk  associated  with  the  contracted  work. 

Soliciting  Bids 

A  solicitation  is  the  process  of  requesting  a  price  and  supporting  information  from  bidders.  The  solicitation  usu¬ 
ally  takes  the  form  of  either  an  RFQ  or  an  RFR  Partnerships  are  pursued  and  established  differently  on  a  case-by¬ 
case  basis  by  senior  management. 

Qualifying  Bidders 

Potential  bidders  are  people  or  organizations  capable  of  providing  the  materials  or  performing  the  work  required 
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for  the  project.  On  smaller,  less  complex  projects,  the  parent  company  typically  has  a  list  of  suppliers  and  vendors 
that  have  successfully  provided  goods  and  services  in  the  past,  and  the  project  has  access  to  the  performance 
record  of  companies  on  that  list.  On  unique  projects,  where  no  supplier  lists  exist,  the  project  team  develops  a 
list  of  potential  suppliers  and  then  qualifies  them  to  become  eligible  to  bid  on  project  work.  Eligible  bidders  are 
placed  on  the  bidders  list  and  provided  with  a  schedule  of  when  work  on  the  project  will  be  put  out  for  bid. 

The  eligibility  of  a  supplier  is  determined  by  the  ability  to  perform  the  work  in  a  way  that  meets  project  require¬ 
ments  and  demonstrates  financial  stability.  Ability  to  perform  the  work  includes  the  ability  to  meet  quality  specifi¬ 
cations  and  the  project  schedule.  During  times  when  economic  activity  is  high  in  a  region,  many  suppliers  become 
busy  and  stretch  their  resources.  The  project  team  investigates  the  potential  suppliers,  before  they  are  included  on 
the  bidder’s  list,  to  ensure  that  they  have  the  capacity  and  track  record  to  meet  deadlines. 

The  potential  supplier  must  also  be  financially  stable  to  be  included  on  the  bidders  list.  A  credit  check  or  a  finan¬ 
cial  report  from  Dun  and  Bradstreet  (D&B) — a  well-known  provider  of  financial  information  about  individual 
companies — will  provide  the  project  with  information  about  the  potential  bidder’s  financial  status.  D&B  services 
include  the  following: 

•  D&B  proprietary  rankings  and  predictive  creditworthiness  scores 

•  Public  filings,  including  suits,  liens,  judgments,  and  UCC  (uniform  commercial  code)  filings — standardized 
financial  disclosure  documents  that  conform  to  the  uniform  commercial  code 

•  Company  financial  statements  and  history 

Request  for  Quote 

An  RFQ  focuses  on  price.  The  type  of  materials  or  service  is  well  defined  and  can  be  obtained  from  several 
sources.  The  bidder  that  can  meet  the  project  quality  and  schedule  requirements  usually  wins  the  contract  by  quot¬ 
ing  the  lowest  price. 

Request  for  Proposal 

An  RFP  accounts  for  price  but  focuses  on  meeting  the  project  quality  or  schedule  requirements.  The  process  of 
developing  a  proposal  in  response  to  an  RFP  can  be  very  expensive  for  the  bidder,  and  the  project  team  should  not 
issue  an  RFP  to  a  company  that  is  not  eligible  to  win  the  bid. 

Evaluating  Bids 

Evaluation  of  bids  in  response  to  RFQs  for  commodity  items  and  services  is  heavily  graded  for  price.  In  most 
cases,  the  lowest  total  price  will  win  the  contract.  The  total  price  will  include  the  costs  of  the  goods  or  services, 
any  shipping  or  delivery  costs,  the  value  of  any  warranties,  and  any  additional  service  that  adds  value  to  the  pro¬ 
ject. 

The  evaluation  of  bids  based  on  RFPs  is  more  complex.  The  evaluation  of  proposals  includes  the  price  and  also  an 
evaluation  of  the  technical  approach  chosen  by  the  bidder.  The  project  team  evaluating  the  proposal  must  include 
people  with  the  expertise  to  understand  the  technical  aspects  of  the  various  proposal  options  and  the  value  of  each 
proposal  to  the  project.  On  more  complex  projects,  the  administrative  part  of  the  proposal  is  evaluated  and  scored 
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by  one  team,  and  the  technical  aspect  of  the  proposal  is  evaluated  by  another  team.  The  project  team  combines  the 
two  scores  to  determine  the  best  proposal  for  the  project. 

Awarding  the  Contract 

After  the  project  team  has  selected  the  bidder  that  provides  the  best  value  for  the  project,  a  project  representative 
validates  all  conditions  of  the  bid  and  the  contract  with  the  potential  contractor.  Less  complex  awards,  like  con¬ 
tracts  for  printed  materials,  require  a  reading  and  signing  of  the  contract  to  ensure  that  the  supplier  understands 
the  contract  terms  and  requirements  of  the  project  schedule.  More  complex  projects  require  a  detailed  discussion 
of  the  goals,  the  potential  barriers  to  accomplishing  those  goals,  the  project  schedule  and  critical  dates,  and  the 
processes  for  resolving  conflicts  and  improving  work  processes. 

Managing  the  Contracts 

The  contract  type  determines  the  level  of  effort  and  the  skills  needed  to  manage  the  contract.  The  manager  of  sup¬ 
plier  contracts  develops  detailed  specifications  and  ensures  compliance  with  these  specifications.  The  manager  of 
vendor  contracts  ensures  that  the  contractors  bidding  on  the  work  have  the  skills  and  capacity  to  accomplish  the 
work  according  to  the  project  schedule  and  tracks  the  vendor’s  performance  against  the  project  needs,  supplying 
support  and  direchon  when  needed.  The  manager  of  partnering  arrangements  develops  alignment  around  common 
goals  and  work  processes.  Each  of  these  approaches  requires  different  skills  and  various  degrees  of  effort. 

Items  that  take  a  long  time  to  acquire — long-lead  items — receive  early  attention  by  the  project  leadership.  Exam¬ 
ples  of  long-lead  items  are  equipment  that  is  designed  and  built  specifically  for  the  project,  curriculum  that  is 
created  for  training  a  new  workforce,  and  a  customized  bioreactor  for  a  biotech  project.  These  items  might  require 
weeks,  months,  or  years  to  develop  and  complete.  The  project  team  identifies  long-lead  items  early  to  begin  the 
procurement  activities  as  soon  as  possible  because  those  procured  through  the  normal  procurement  cycle  may 
cause  delays  in  the  project. 

After  the  contract  is  awarded,  the  project  team  tracks  the  performance  of  the  contractor  against  performance  cri¬ 
teria  in  the  contract  and  his  or  her  contribution  to  the  performance  of  the  project.  Usually,  contractors  deliver 
the  product  or  service  that  meets  the  quality  expectations  and  supports  the  project  schedule.  Typically,  there  are 
also  one  or  two  contractors  that  do  not  perform  to  project  expectations.  Some  project  managers  will  refer  to  the 
contract  and  use  it  to  attempt  to  persuade  the  contractor  to  improve  performance  or  be  penalized.  Other  project 
managers  will  explore  with  the  contractor  creative  ways  to  improve  performance  and  meet  project  requirements. 
The  contract  management  allows  for  both  approaches  to  deal  with  non'-performing  contractors,  and  the  project 
team  must  assess  what  method  is  most  likely  to  work  in  each  situation. 

Managing  contractor  performance  on  a  project  is  as  important  to  the  overall  project  outcomes  as  the  work  per¬ 
formed  by  the  project  team. 

Logistics  and  Expediting 

Equipment  and  materials  that  are  purchased  for  use  on  the  project  must  be  transported,  inventoried,  warehoused, 
and  often  secured.  This  area  of  expertise  is  called  logistics.  The  logistics  for  the  project  can  be  managed  by  the 
project  team  or  can  be  included  in  the  RFP  or  RFQ.  On  international  projects,  materials  may  be  imported,  and 
the  procurement  team  manages  the  customs  process.  On  smaller  projects,  the  logistical  function  is  often  provided 
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by  the  parent  company.  On  larger  projects,  these  activities  are  typically  contracted  to  companies  that  specialize  in 
logistical  services.  On  larger,  more  complex  projects,  the  procurement  team  will  include  logistical  expertise. 

The  project  work  often  depends  on  materials  procured  for  the  project.  The  delivery  of  these  materials  influences 
the  scheduling  of  the  project,  and  often  some  materials  are  needed  earlier  than  normal  procurement  practices 
would  deliver.  On  long-lead  items,  the  project  schedule  is  included  in  the  contracting  plans  and  contractors  must 
explain  how  they  will  support  the  project  schedule. 

On  large,  complex  projects,  critical  items  might  be  scheduled  for  delivery  after  they  are  needed  on  the  project.  The 
procurement  team  then  explores  ideas  with  the  contractor  to  expedite  the  manufacturing  or  transportation  of  the 
equipment  or  materials.  The  contract  can  often  place  a  priority  on  the  fabrication  of  the  equipment  and  delivery 
of  the  equipment  to  meet  the  project  schedule.  The  project  logistics  team  can  also  explore  ways  of  shortening  the 
transportation  time.  For  example,  a  project  in  Argentina  flew  some  critical  equipment  from  Sweden  rather  than 
transport  the  equipment  by  ship  to  save  several  weeks  in  transit.  The  logistics  costs  were  higher,  but  the  overall 
value  to  the  project  was  greater. 
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ADRIENNE  WATT 


It’s  not  enough  to  make  sure  you  get  a  project  done  on  time  and  under  budget.  You  need  to  be  sure  you  make  the 
right  product  to  suit  your  stakeholders’  needs.  Quality  means  making  sure  that  you  build  what  you  said  you  would 
and  that  you  do  it  as  efficiently  as  you  can.  And  that  means  trying  not  to  make  too  many  mistakes  and  always 
keeping  your  project  working  toward  the  goal  of  creating  the  right  product. 

Everybody  “knows”  what  quality  is.  But  the  way  the  word  is  used  in  everyday  life  is  a  little  different  from  how 
it  is  used  in  project  management.  Just  like  the  triple  constraint  (scope,  cost,  and  schedule),  you  manage  quality 
on  a  project  by  setting  goals  and  taking  measurements.  That’s  why  you  must  understand  the  quality  levels  your 
stakeholders  believe  are  acceptable,  and  ensure  that  your  project  meets  those  targets,  just  like  it  needs  to  meet 
their  budget  and  schedule  goals. 

Customer  satisfaction  is  about  making  sure  that  the  people  who  are  paying  for  the  end  product  are  happy  with 
what  they  get.  When  the  team  gathers  requirements  for  the  specification,  they  try  to  write  down  all  of  the  things 
that  the  customers  want  in  the  product  so  that  you  know  how  to  make  them  happy.  Some  requirements  can  be  left 
unstated.  Those  are  the  ones  that  are  implied  by  the  customer’s  explicit  needs.  For  example,  some  requirements 
are  just  common  sense  (e.g.,  a  product  that  people  hold  can’t  be  made  from  toxic  chemicals  that  may  kill  them). 
It  might  not  be  stated,  but  it’s  definitely  a  requirement. 

“Fitness  to  use”  is  about  making  sure  that  the  product  you  build  has  the  best  design  possible  to  fit  the  customer’s 
needs.  Which  would  you  choose:  a  product  that’s  beautifully  designed,  well  constructed,  solidly  built,  and  all 
around  pleasant  to  look  at  but  does  not  do  what  you  need,  or  a  product  that  does  what  you  want  despite  being  ugly 
and  hard  to  use?  You’ll  always  choose  the  product  that  fits  your  needs,  even  if  it’s  seriously  limited.  That’s  why 
it’s  important  that  the  product  both  does  what  it  is  supposed  to  do  and  does  it  well.  For  example,  you  could  pound 
in  a  nail  with  a  screwdriver,  but  a  hammer  is  a  better  fit  for  the  job. 

Conformance  to  requirements  is  the  core  of  both  customer  satisfaction  and  fitness  to  use,  and  is  a  measure  of 
how  well  your  product  does  what  you  intend.  Above  all,  your  product  needs  to  do  what  you  wrote  down  in  your 
requirements  document.  Your  requirements  should  take  into  account  what  will  satisfy  your  customer  and  the  best 
design  possible  for  the  job.  That  means  conforming  to  both  stated  and  implied  requirements. 
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In  the  end,  your  product’s  quality  is  judged  by  whether  you  built  what  you  said  you  would  build. 

Quality  planning  focuses  on  taking  all  of  the  information  available  to  you  at  the  beginning  of  the  project  and 
figuring  out  how  you  will  measure  quality  and  prevent  defects.  Your  company  should  have  a  quality  policy  that 
states  how  it  measures  quality  across  the  organization.  You  should  make  sure  your  project  follows  the  company 
policy  and  any  government  rules  or  regulations  on  how  to  plan  quality  for  your  project. 

You  need  to  plan  which  activities  you  will  use  to  measure  the  quality  of  the  project’s  product.  And  you’ll  need  to 
think  about  the  cost  of  all  the  quality-related  activities  you  want  to  do.  Then  you’ll  need  to  set  some  guidelines 
for  what  you  will  measure  against.  Finally,  you’ll  need  to  design  the  tests  you  will  run  when  the  product  is  ready 
to  be  tested. 


Quality  and  Grade 

According  to  the  International  Organization  for  Standardization  (ISO),  quality  is  “the  degree  to  which  a  set  of 
inherent  characteristics  fulfill  requirements.”  The  requirements  of  a  product  or  process  can  be  categorized  or  given 
a  grade  that  will  provide  a  basis  for  comparison.  The  quality  is  determined  by  how  well  something  meets  the 
requirements  of  its  grade. 

For  most  people,  the  term  quality  also  implies  good  value — getting  your  money’s  worth.  For  example,  even  low- 
grade  products  should  still  work  as  expected,  be  safe  to  use,  and  last  a  reasonable  amount  of  time.  Consider  the 
following  examples. 

Example:  Quality  of  Gasoline  Grades 

Petroleum  refiners  provide  gasoline  in  several  different  grades  based  on  the  octane  rating  because  higher  octane 
ratings  are  suitable  for  higher  compression  engines.  Gasoline  must  not  be  contaminated  with  dirt  or  water,  and 
the  actual  performance  of  the  fuel  must  be  close  to  its  octane  rating.  A  shipment  of  low-grade  gasoline  graded  as 
87  octane  that  is  free  of  water  or  other  contaminants  would  be  of  high  quality,  while  a  shipment  of  high-grade  93 
octane  gas  that  is  contaminated  with  dirt  would  be  of  low  quality. 

Example:  Quality  of  Furniture  Packing 

John  has  antique  furniture  in  excellent  condition  that  was  left  to  him  by  his  grandmother.  The  pieces  are  important 
to  John  for  sentimental  reasons,  and  they  are  valuable.  John  decides  to  hire  movers  (high-grade  professionals)  to 
load  his  furniture  into  the  truck  using  appropriate  padding  and  restraints  to  prevent  dents  and  scratches  during  the 
move.  John’s  standard  for  high  quality  is  that  no  observable  damage  occurs  to  his  large  pieces  of  furniture,  espe¬ 
cially  the  antiques.  If  the  furniture  arrives  in  his  new  apartment  without  a  single  dent,  scratch,  or  other  damage, 
the  activity  will  be  of  high  quality.  John’s  standard  for  packing  his  kitchen  is  lower.  His  dishes  are  old  and  cheap, 
so  he  decides  to  trust  his  inexperienced  friends  (low-grade  amateurs)  to  help  him  pack  his  kitchen.  If  a  few  of  the 
dishes  or  glassware  are  chipped  or  broken  in  the  process,  the  savings  in  labor  cost  will  more  than  make  up  for  the 
loss  and  will  be  a  good  value. 
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Statistics 

Determining  how  well  products  meet  grade  requirements  is  done  by  taking  measurements  and  then  interpreting 
those  measurements.  Statistics — the  mathematical  interpretation  of  numerical  data — are  useful  when  interpreting 
large  numbers  of  measurements  and  are  used  to  determine  how  well  the  product  meets  a  specification  when  the 
same  product  is  made  repeatedly.  Measurements  made  on  samples  of  the  product  must  be  within  control  lim¬ 
its — the  upper  and  lower  extremes  of  allowable  variation — and  it  is  up  to  management  to  design  a  process  that 
will  consistendy  produce  products  between  those  limits. 

Instructional  designers  often  use  statistics  to  determine  the  quality  of  their  course  designs.  Student  assessments 
are  one  way  in  which  instructional  designers  are  able  to  tell  whether  learning  occurs  within  the  control  limits. 

Example:  Setting  Control  Limits 

A  petroleum  refinery  produces  large  quantities  of  fuel  in  several  grades.  Samples  of  the  fuels  are  extracted  and 
measured  at  regular  intervals.  If  a  fuel  is  supposed  to  have  an  87  octane  performance,  samples  of  the  fuel  should 
produce  test  results  that  are  close  to  that  value.  Many  of  the  samples  will  have  scores  that  are  different  from  87. 
The  differences  are  due  to  random  factors  that  are  difficult  or  expensive  to  control.  Most  of  the  samples  should  be 
close  to  the  87  rating  and  none  of  them  should  be  too  far  off.  The  manufacturer  has  grades  of  85  and  89,  so  they 
decide  that  none  of  the  samples  of  the  87  octane  fuel  should  be  less  than  86  or  higher  than  88. 

If  a  process  is  designed  to  produce  a  product  of  a  certain  size  or  other  measured  characteristic,  it  is  impossible  to 
control  all  the  small  factors  that  can  cause  the  product  to  differ  slightly  from  the  desired  measurement.  Some  of 
these  factors  will  produce  products  that  have  measurements  that  are  larger  than  desired  and  some  will  have  the 
opposite  effect.  If  several  random  factors  are  affecting  the  process,  they  tend  to  offset  each  other,  and  the  most 
common  results  are  near  the  middle  of  the  range;  this  phenomenon  is  called  the  central  limit  theorem. 

If  the  range  of  possible  measurement  values  is  divided  equally  into  subdivisions  called  bins,  the  measurements 
can  be  sorted,  and  the  number  of  measurements  that  fall  into  each  bin  can  be  counted.  The  result  is  a  frequency 
distribution  that  shows  how  many  measurements  fall  into  each  bin.  If  the  effects  that  are  causing  the  differences 
are  random  and  tend  to  offset  each  other,  the  frequency  distribution  is  called  a  normal  distribution,  which  resem¬ 
bles  the  shape  of  a  bell  with  edges  that  flare  out.  The  edges  of  a  theoretical  normal  distribution  curve  get  very 
close  to  zero  but  do  not  reach  zero. 

Example:  Normal  Distribution 

A  refinery’s  quality  control  manager  measures  many  samples  of  87  octane  gasoline,  sorts  the  measurements  by 
their  octane  rating  into  bins  that  are  0.1  octane  wide,  and  then  counts  the  number  of  measurements  in  each  bin. 
Then  she  creates  a  frequency  distribution  chart  of  the  data,  as  shown  in  Figure  14.1. 

It  is  common  to  take  samples — randomly  selected  subsets  from  the  total  population — and  measure  and  compare 
their  qualities,  since  measuring  the  entire  population  would  be  cumbersome,  if  not  impossible.  If  the  sample  mea¬ 
surements  are  distributed  equally  above  and  below  the  center  of  the  distribution  as  they  are  in  Figure  14.1,  the 
average  of  those  measurements  is  also  the  center  value  that  is  called  the  mean,  and  is  represented  in  formulas  by 
the  lowercase  Greek  letter  p  (pronounced  mu).  The  amount  of  difference  of  the  measurements  from  the  central 
value  is  called  the  sample  standard  deviation  or  just  the  standard  deviation. 
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The  first  step  in  calculating  the  standard  deviation  is  subtracting  each  measurement  from  the  central  value  (mean) 
and  then  squaring  that  difference.  (Recall  from  your  mathematics  courses  that  squaring  a  number  is  multiplying 
it  by  itself  and  that  the  result  is  always  positive.)  The  next  step  is  to  sum  these  squared  values  and  divide  by  the 
number  of  values  minus  one.  The  last  step  is  to  take  the  square  root.  The  result  can  be  thought  of  as  an  average 
difference.  (If  you  had  used  the  usual  method  of  taking  an  average,  the  positive  and  negative  numbers  would  have 
summed  to  zero.)  Mathematicians  represent  the  standard  deviation  with  the  lowercase  Greek  letter  a  (pronounced 
sigma).  If  all  the  elements  of  a  group  are  measured,  instead  of  just  a  sample,  it  is  called  the  standard  deviation  of 
the  population  and  in  the  second  step,  the  sum  of  the  squared  values  is  divided  by  the  total  number  of  values. 


Figure  14.1  Normal  Distribution  of  Measurements 
Source:  http://pm4id.Org/10/l/ 


Figure  14.1  shows  that  the  most  common  measurements  of  octane  rating  are  close  to  87  and  that  the  other  mea¬ 
surements  are  distributed  equally  above  and  below  87.  The  shape  of  the  distribution  chart  supports  the  central 
limit  theorem’s  assumption  that  the  factors  that  are  affecting  the  octane  rating  are  random  and  tend  to  offset  each 
other,  which  is  indicated  by  the  symmetric  shape.  This  distribution  is  a  classic  example  of  a  normal  distribution. 
The  quality  control  manager  notices  that  none  of  the  measurements  are  above  88  or  below  86  so  they  are  within 
control  limits,  and  she  concludes  that  the  process  is  working  satisfactorily. 


Example:  Standard  Deviation  of  Gasoline  Samples 

The  refinery’s  quality  control  manager  uses  the  standard  deviation  function  in  her  spreadsheet  program  to  find  the 
standard  deviation  of  the  sample  measurements  and  finds  that  for  her  data,  the  standard  deviation  is  0.3  octane. 
She  marks  the  range  on  the  frequency  distribution  chart  to  show  the  values  that  fall  within  one  sigma  (standard 
deviation)  on  either  side  of  the  mean  (Figure  14.2). 


Figure  14.2  One  Sigma  Range 

Most  of  the  measurements  are  within  0.3  octane  of  87. 
Source:  http://pm4id.Org/10/l/ 


For  normal  distributions,  about  68.3%  of  the  measurements  fall  within  one  standard  deviation  on  either  side  of 
the  mean.  This  is  a  useful  rule  of  thumb  for  analyzing  some  types  of  data.  If  the  variation  between  measurements 
is  caused  by  random  factors  that  result  in  a  normal  distribution,  and  someone  tells  you  the  mean  and  the  standard 
deviation,  you  know  that  a  little  over  two-thirds  of  the  measurements  are  within  a  standard  deviation  on  either  side 
of  the  mean.  Because  of  the  shape  of  the  curve,  the  number  of  measurements  within  two  standard  deviations  is 
95.4%,  and  the  number  of  measurements  within  three  standard  deviations  is  99.7%.  For  example,  if  someone  said 
the  average  (mean)  height  for  adult  men  in  the  United  States  is  178  cm  (70  inches)  and  the  standard  deviation  is 
about  8  cm  (3  inches),  you  would  know  that  68%  of  the  men  in  the  United  States  are  between  170  cm  (67  inches) 
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and  186  cm  (73  inches)  in  height.  You  would  also  know  that  about  95%  of  the  adult  men  in  the  United  States  were 
between  162  cm  (64  inches)  and  194  cm  (76  inches)  tall,  and  that  almost  all  of  them  (99.7%)  are  between  154  cm 
(61  inches)  and  202  cm  (79  inches)  tall.  These  figures  are  referred  to  as  the  68-95-99.7  rule. 

Example:  Gasoline  Within  Three  Standard  Deviations 

The  refinery’s  quality  control  manager  marks  the  ranges  included  within  two  and  three  standard  deviations,  as 
shown  in  Figure  14.3.  Some  products  must  have  less  variability  than  others  to  meet  their  purpose.  For  example, 
if  training  designed  to  operate  highly  specialized  and  potentially  dangerous  machinery  was  assessed  for  quality, 
most  participants  would  be  expected  to  exceed  the  acceptable  pass  rate.  Three  standard  deviations  from  the  con¬ 
trol  limits  might  be  fine  for  some  products  but  not  for  others.  In  general,  if  the  mean  is  six  standard  deviations 
from  both  control  limits,  the  likelihood  of  a  part  exceeding  the  control  limits  from  random  variation  is  practically 
zero  (2  in  1,000,000,000). 


Figure  14.3  The  68-95-99.7  Rule 
Source:  http://pm4id.Org/10/l/ 


Example:  A  Step  Project  Improves  Quality  of  Gasoline 

A  new  refinery  process  is  installed  that  produces  fuels  with  less  variability.  The  refinery’s  quality  control  manager 
takes  a  new  set  of  samples  and  charts  a  new  frequency  distribution  diagram,  as  shown  in  Figure  14.4.The  refin¬ 
ery’s  quality  control  manager  calculates  that  the  new  standard  deviation  is  0.2  octane.  From  this,  she  can  use  the 
68-95-99.7  rule  to  estimate  that  68.3%  of  the  fuel  produced  will  be  between  86.8  and  87.2  and  that  99.7%  will 
be  between  86.4  and  87.6  octane.  A  shorthand  way  of  describing  this  amount  of  control  is  to  say  that  it  is  a  five- 
sigma  production  system,  which  refers  to  the  five  standard  deviations  between  the  mean  and  the  control  limit  on 
each  side. 


Figure  14.4  Smaller  Standard  Deviation 
Source:  http://pm4id.Org/10/l/ 


Quality  planning  tools 

High  quality  is  achieved  by  planning  for  it  rather  than  by  reacting  to  problems  after  they  are  identified.  Standards 
are  chosen  and  processes  are  put  in  place  to  achieve  those  standards. 

Measurement  Terminology 

During  the  execution  phase  of  the  project,  services  and  products  are  sampled  and  measured  to  determine  if  the 
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quality  is  within  control  limits  for  the  requirements  and  to  analyze  causes  for  variations.  This  evaluation  is  often 
done  by  a  separate  quality  control  group,  and  knowledge  of  a  few  process  measurement  terms  is  necessary  to 
understand  their  reports.  Several  of  these  terms  are  similar,  and  it  is  valuable  to  know  the  distinction  between 
them. 

The  quality  plan  specifies  the  control  limits  of  the  product  or  process;  the  size  of  the  range  between  those  limits 
is  the  tolerance.  Tolerances  are  often  written  as  the  mean  value,  plus  or  minus  the  tolerance.  The  plus  and  minus 
signs  are  written  together,  ±. 

Example:  Tolerance  in  Gasoline  Production 

The  petroleum  refinery  chose  to  set  its  control  limits  for  87  octane  gasoline  at  86  and  88  octane.  The  tolerance  is 
87  ±  1. 

Tools  are  selected  that  can  measure  the  samples  closely  enough  to  determine  if  the  measurements  are  within  con¬ 
trol  limits  and  if  they  are  showing  a  trend.  Each  measurement  tool  has  its  own  tolerances. 

The  choice  of  tolerance  directly  affects  the  cost  of  quality  (COQ).  In  general,  it  costs  more  to  produce  and  measure 
products  that  have  small  tolerances.  The  costs  associated  with  making  products  with  small  tolerances  for  variation 
can  be  very  high  and  not  proportional  to  the  gains.  For  example,  if  the  cost  of  evaluating  each  screen  as  it  is  cre¬ 
ated  in  an  online  tutorial  is  greater  than  delivering  the  product  and  fixing  any  issues  after  the  fact,  then  the  COQ 
may  be  too  high  and  the  instructional  designer  will  tolerate  more  defects  in  the  design. 

Defining  and  Meeting  Client  Expectations 

Clients  provide  specifications  for  the  project  that  must  be  met  for  the  project  to  be  successful.  Recall  that  meeting 
project  specifications  is  one  definition  of  project  success.  Clients  often  have  expectations  that  are  more  difficult 
to  capture  in  a  written  specification.  For  example,  one  client  will  want  to  be  invited  to  every  meeting  of  the  pro¬ 
ject  and  will  then  select  the  ones  that  seem  most  relevant.  Another  client  will  want  to  be  invited  only  to  project 
meetings  that  need  client  input.  Inviting  this  client  to  every  meeting  will  cause  unnecessary  frustration.  Listening 
to  the  client  and  developing  an  understanding  of  the  expectations  that  are  not  easily  captured  in  specifications  is 
important  to  meeting  those  expectations. 

Project  surveys  can  capture  how  the  client  perceives  the  project  performance  and  provide  the  project  team  with 
data  that  are  useful  in  meeting  client  expectations.  If  the  results  of  the  surveys  indicate  that  the  client  is  not  pleased 
with  some  aspect  of  the  project,  the  project  team  has  the  opportunity  to  explore  the  reasons  for  this  perception 
with  the  client  and  develop  recovery  plans.  The  survey  can  also  help  define  what  is  going  well  and  what  needs 
improvement. 

Sources  of  Planning  Information 

Planning  for  quality  is  part  of  the  initial  planning  process.  The  early  scope,  budget,  and  schedule  estimates  are 
used  to  identify  processes,  services,  or  products  where  the  expected  grade  and  quality  should  be  specified.  Risk 
analysis  is  used  to  determine  which  of  the  risks  to  the  project  could  affect  quality. 
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Techniques 

Several  different  tools  and  techniques  are  available  for  planning  and  controlling  the  quality  of  a  project.  The  extent 
to  which  these  tools  are  used  is  determined  by  the  project  complexity  and  the  quality  management  program  in  use 
by  the  client. 

The  following  represents  the  quality  planning  tools  available  to  the  project  manager. 

Cost-benefit  analysis  is  looking  at  how  much  your  quality  activities  will  cost  versus  how  much  you  will  gain 
from  doing  them.  The  costs  are  easy  to  measure;  the  effort  and  resources  it  takes  to  do  them  are  just  like  any  other 
task  on  your  schedule.  Since  quality  activities  don’t  actually  produce  a  product,  it  is  sometimes  harder  for  people 
to  measure  the  benefit.  The  main  benefits  are  less  reworking,  higher  productivity  and  efficiency,  and  more  satis¬ 
faction  from  both  the  team  and  the  customer. 

Benchmarking  means  using  the  results  of  quality  planning  on  other  projects  to  set  goals  for  your  own.  You  might 
find  that  the  last  project  in  your  company  had  20%  fewer  defects  than  the  one  before  it.  You  should  want  to  learn 
from  a  project  like  that  and  put  in  practice  any  of  the  ideas  they  used  to  make  such  a  great  improvement.  Bench¬ 
marks  can  give  you  some  reference  points  for  judging  your  own  project  before  you  even  start  the  work. 

Design  of  experiments  is  the  list  of  all  the  kinds  of  tests  you  are  going  to  run  on  your  product.  It  might  list  all 
the  kinds  of  test  procedures  you’ll  do,  the  approaches  you’ll  take,  and  even  the  tests  themselves.  (In  the  software 
world,  this  is  called  test  planning.) 

Cost  of  quality  is  what  you  get  when  you  add  up  the  cost  of  all  the  prevention  and  inspection  activities  you  are 
going  to  do  on  your  project.  It  doesn’t  just  include  the  testing.  It  includes  any  time  spent  writing  standards,  review¬ 
ing  documents,  meeting  to  analyze  the  root  causes  of  defects,  reworking  to  fix  the  defects  once  they’re  found  by 
the  team:  in  other  words,  absolutely  everything  you  do  to  ensure  quality  on  the  project.  Cost  of  quality  can  be 
a  good  number  to  check  to  determine  whether  your  project  is  doing  well  or  having  trouble.  Say  your  company 
tracks  the  cost  of  quality  on  all  of  its  projects;  then  you  could  tell  if  you  are  spending  more  or  less  than  has  been 
spent  on  other  projects  to  get  your  project  up  to  quality  standards. 

Control  charts  can  be  used  to  define  acceptable  limits.  If  some  of  the  functions  of  a  project  are  repetitive,  sta¬ 
tistical  process  controls  can  be  used  to  identify  trends  and  keep  the  processes  within  control  limits.  Part  of  the 
planning  for  controlling  the  quality  of  repetitive  processes  is  to  determine  what  the  control  limits  are  and  how  the 
process  will  be  sampled. 

Cause-and-effect  diagrams  can  help  in  discovering  problems.  When  control  charts  indicate  an  assignable  cause 
for  a  variation,  it  is  not  always  easy  to  identify  the  cause  of  a  problem.  Discussions  that  are  intended  to  discover 
the  cause  can  be  facilitated  using  a  cause-and-effect  or  fishbone  diagram  where  participants  are  encouraged  to 
identify  possible  causes  of  a  defect. 

Example;  Diagramming  Quality  Problems 

A  small  manufacturing  firm  tries  to  identify  the  assignable  causes  to  variations  in  its  manufacturing  line.  They 
assemble  a  team  that  identifies  six  possibilities,  as  shown  in  the  fishbone  diagram  in  Figure  14.5. 


146  •  PROJECT  MANAGEMENT 


Figure  14.5  Cause-and-Effect  (Fishbone)  Diagram 
Source:  http://pm4id.Org/10/4/ 


Each  branch  of  the  diagram  can  be  expanded  to  break  down  a  category  into  more  specific  items.  An  engineer  and 
an  electrician  work  on  one  of  the  branches  to  consider  possible  causes  of  power  fluctuation  and  add  detail  to  their 
part  of  the  fishbone  diagram,  as  shown  in  Figure  14.6. 


Figure  14.6  Possible  Causes  of  Power  Fluctuation 
Source:  http://pm4id.Org/10/4/ 


Check  sheets,  histograms,  and  Pareto  charts  are  used  to  solve  several  quality  problems.  When  a  quality-control 
issue  occurs,  a  project  manager  must  choose  which  problem  to  address  first.  One  way  to  prioritize  quality  prob¬ 
lems  is  to  determine  which  ones  occur  most  frequently.  These  data  can  be  collected  using  a  check  sheet,  which 
is  a  basic  form  on  which  the  user  can  make  a  check  in  the  appropriate  box  each  time  a  problem  occurs  or  by 
automating  the  data  collection  process  using  the  appropriate  technology.  Once  the  data  are  collected,  they  can  be 
analyzed  by  creating  a  type  of  frequency  distribution  chart  called  a  histogram.  A  true  histogram  is  a  column  chart 
where  the  widths  of  the  columns  fill  the  available  space  on  the  x-axis  axis  and  are  proportional  to  the  category 
values  displayed  on  that  axis,  while  the  height  of  the  columns  is  proportional  to  the  frequency  of  occurrences. 
Most  histograms  use  one  width  of  column  to  represent  a  category,  while  the  vertical  axis  represents  the  frequency 
of  occurrences. 

A  variation  on  the  histogram  is  a  frequency  distribution  chart  invented  by  economist  Vilfredo  Pareto  known  as  a 
Pareto  chart,  in  which  the  columns  are  arranged  in  decreasing  order  with  the  most  common  on  the  left  and  a  line 
added  that  shows  the  cumulative  total.  The  combination  of  columns  and  a  line  allows  the  user  to  tell  at  a  glance 
which  problems  are  most  frequent  and  what  fraction  of  the  total  they  represent. 

Once  you  have  your  quality  plan,  you  know  your  guidelines  for  managing  quality  on  the  project.  Your  strategies 
for  monitoring  project  quality  should  be  included  in  the  plan,  as  well  as  the  reasons  for  all  the  steps  you  are  taking. 
It’s  important  that  everyone  on  the  team  understand  the  rationale  behind  the  metrics  being  used  to  judge  success 
or  failure  of  the  project. 


Quality  Assurance 

The  purpose  of  quality  assurance  is  to  create  confidence  that  the  quality  plan  and  controls  are  working  properly. 
Time  must  be  allocated  to  review  the  original  quality  plan  and  compare  that  plan  to  how  quality  is  being  ensured 
during  the  implementation  of  the  project. 
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Process  Analysis 

The  flowcharts  of  quality  processes  are  compared  to  the  processes  followed  during  actual  operations.  If  the  plan 
was  not  followed,  the  process  is  analyzed  and  corrective  action  taken.  The  corrective  action  could  be  to  educate 
the  people  involved  on  how  to  follow  the  quality  plan,  or  it  could  be  to  revise  the  plan. 

The  experiments  that  sample  products  and  processes  and  collect  data  are  examined  to  see  if  they  are  following 
statistically  valid  sampling  techniques  and  that  the  measurement  methods  have  small  enough  tolerances  to  detect 
variation  within  control  limits. 

Because  projects  are  temporary,  there  are  fewer  opportunities  to  learn  and  improve  within  a  project,  especially  if 
it  has  a  short  duration.  But  even  in  short  projects,  the  quality  manager  should  have  a  way  to  learn  from  experience 
and  change  the  process  for  the  next  project  of  a  similar  complexity  profile. 

Example:  Analyzing  Quality  Processes  in  Safety  Training 

A  technical  college  responsible  for  training  employees  in  safe  plant  practices  evaluates  its  instructor  selection 
process  at  the  end  of  the  training  to  see  if  it  had  the  best  criteria  for  selection.  For  example,  it  required  the  instruc¬ 
tors  to  have  master’s  degrees  in  manufacturing  to  qualify  as  college  instructors.  The  college  used  an  exit  survey  of 
the  students  to  ask  what  they  thought  would  improve  the  instruction  of  future  classes  on  this  topic.  Some  students 
felt  that  it  would  be  more  important  to  require  that  the  instructors  have  more  years  of  training  experience,  while 
others  recommended  that  instructors  seek  certification  at  a  training  center.  The  college  considered  these  sugges¬ 
tions  and  decided  to  retain  its  requirement  of  a  master’s  degree  but  add  a  requirement  that  instructors  be  certified 
in  plant  safety. 

The  purpose  of  quality  assurance  is  to  build  confidence  in  the  client  that  quality  standards  and  procedures  are 
being  followed.  This  is  done  by  an  internal  review  of  the  plan,  testing,  and  revisions  policies  or  by  an  audit  of  the 
same  items  performed  by  an  external  group  or  agency. 
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15.  Communication  Planning 


ADRIENNE  WATT 


Communications  management  is  about  keeping  everybody  in  the  loop.  The  communications  planning  process 
concerns  defining  the  types  of  information  you  will  deliver,  who  will  receive  it,  the  format  for  communicating  it, 
and  the  timing  of  its  release  and  distribution.  It  turns  out  that  90%  of  a  project  manager’s  job  is  spent  on  commu¬ 
nication  so  it’s  important  to  make  sure  everybody  gets  the  right  message  at  the  right  time. 

The  first  step  in  defining  your  communication  plan  is  figuring  out  what  kind  of  communication  your  stakeholders 
need  from  the  project  so  they  can  make  good  decisions.  This  is  called  the  communications  requirements  analysis. 
Your  project  will  produce  a  lot  of  information;  you  don’t  want  to  overwhelm  your  stakeholders  with  all  of  it.  Your 
job  is  to  figure  out  what  they  feel  is  valuable.  Communicating  valuable  information  doesn’t  mean  you  always 
paint  a  rosy  picture.  Communications  to  stakeholders  may  consist  of  either  good  news  or  bad  news.  The  point  is 
that  you  don’t  want  to  bury  stakeholders  in  too  much  information  but  you  do  want  to  give  them  enough  so  that 
they’re  informed  and  can  make  appropriate  decisions. 

Communications  technology  has  a  major  impact  on  how  you  keep  people  in  the  loop.  Methods  of  communicating 
can  take  many  forms,  such  as  written  reports,  conversations,  email,  formal  status  reports,  meetings,  online  data¬ 
bases,  online  schedules,  and  project  websites.  You  should  consider  several  factors  before  deciding  what  methods 
you’ll  choose  to  transfer  information.  The  timing  of  the  information  exchange  or  need  for  updates  is  the  first  fac¬ 
tor.  Do  you  need  to  procure  new  technology  or  systems,  or  are  there  systems  already  in  place  that  will  work? 
The  technologies  available  to  you  should  figure  into  your  plan  of  how  you  will  keep  everyone  notified  of  pro¬ 
ject  status  and  issues.  Staff  experience  with  the  technology  is  another  factor.  Are  there  project  team  members  and 
stakeholders  experienced  at  using  this  technology,  or  will  you  need  to  train  them?  Finally,  consider  the  duration 
of  the  project  and  the  project  environment.  Will  the  technology  you’re  choosing  work  throughout  the  life  of  the 
project  or  will  it  have  to  be  upgraded  or  updated  at  some  point?  And  how  does  the  project  team  function?  Are 
they  located  together  or  spread  out  across  several  campuses  or  locations? 

The  answers  to  these  questions  should  be  documented  in  the  communication  plan. 

All  projects  require  a  sound  communication  plan,  but  not  all  projects  will  have  the  same  types  of  communication 
or  the  same  methods  for  distributing  the  information.  The  communication  plan  documents  the  types  of  information 
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needs  the  stakeholders  have,  when  the  information  should  be  distributed,  and  how  the  information  will  be  deliv¬ 
ered. 

The  types  of  information  you  will  communicate  typically  include  project  status,  project  scope  statements  and 
updates,  project  baseline  information,  risks,  action  items,  performance  measures,  project  acceptance,  and  so  on. 
It’s  important  that  the  information  needs  of  the  stakeholders  be  determined  as  early  in  the  planning  phase  of  the 
project  management  life  cycle  as  possible  so  that  as  you  and  your  team  develop  project  planning  documents,  you 
already  know  who  should  receive  copies  of  them  and  how  they  should  be  delivered. 


Types  of  Communication 

Completing  a  complex  project  successfully  requires  good  communication  among  team  members.  If  those  team 
members  work  in  the  same  building,  they  can  arrange  regular  meetings,  simply  stop  by  each  other’s  office  space  to 
get  a  quick  answer,  or  even  discuss  a  project  informally  at  other  office  functions.  Many  projects  are  performed  by 
teams  that  interact  primarily  through  electronic  communication  and  are,  therefore,  called  virtual  teams.  To  avoid 
miscommunication  that  can  harm  trust  and  to  include  team  members  in  a  project  culture,  the  project  team  needs 
a  plan  for  communicating  reliably  and  in  a  timely  manner.  This  planning  begins  with  understanding  two  major 
categories  of  communication. 

Synchronous  Communications 

If  all  the  parties  to  the  communication  are  taking  part  in  the  exchange  at  the  same  time,  the  communication  is 
synchronous.  A  telephone  or  Skype  conference  call  is  an  example  of  synchronous  communication.  The  following 
are  examples  of  synchronous  communications: 

•  Live  meeting:  Gathering  of  team  members  at  the  same  location 

•  Conference  call:  A  telephone  call  in  which  several  people  participate 

•  Audio  conference:  Like  a  conference  call,  but  conducted  online  using  software  like  Skype 

•  Computer-assisted  conference:  Audio  conference  with  a  connection  between  computers  that  can  display  a 
document  or  spreadsheet  that  can  be  edited  by  both  parties 

•  Video  conference:  Similar  to  an  audio  conference  but  with  live  video  of  the  participants.  Some  laptop  com¬ 
puters  have  built-in  cameras  to  facilitate  video  conferencing 

•  IM  (instant  messaging):  Exchange  of  text  or  voice  messages  using  pop-up  windows  on  the  participants’ 
computer  screens 

•  Texting:  Exchange  of  text  messages  between  mobile  phones,  pagers,  or  personal  digital  assistants 
(PDAs) — devices  that  hold  a  calendar,  a  contact  list,  a  task  list,  and  other  support  programs 

Modern  communication  technologies  make  it  possible  to  assemble  project  teams  from  anywhere  in  the  world. 
Most  people  work  during  daylight  hours,  which  can  make  synchronous  meetings  difficult  if  the  participants  are  in 
different  time  zones.  However,  it  can  be  an  advantage  in  some  circumstances;  for  example,  if  something  must  be 
done  by  the  start  of  business  tomorrow,  team  members  in  Asia  can  work  on  the  problem  during  their  normal  work 
hours  while  team  members  in  North  America  get  some  sleep. 
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Remember  Time  Zones 


It  is  important  to  remember  time  zones  and  calculate  the  difference  between  yours  and  your  associates’  zones 
correctly  so  as  not  to  miss  important  meetings  or  deadlines.  Cities  and  countries  to  the  north  or  south  of  each 
other  all  observe  the  same  local  time.  Be  aware  that  many  well-educated  people  in  the  United  States  and  Canada 
think  of  South  America  as  directly  south  of  North  America.  As  you  can  see,  South  American  countries  can 
be  up  to  five  time  zones  east  of  North  America.  A  helpful  site  to  convert  local  time  to  another  time  zone  is 
http://www.timezoneconverter.com/cgi-bin/tzc.tzc 


Figure  15.1:  World  Time  Zones. 

Standard  time  zones  of  the  world  by  TimeZonesBoy 

(http://commons.wikimedia.org/wiki/ 

File:Standard_time_zones_of_the_world.png)  under  the  Public 
Domain 


Time  zones  are  calculated  in  reference  to  the  time  zone  of  the  Royal  Observatory  in  Greenwich,  England.  The 
time  at  that  location  is  Greenwich  Mean  Time  (GMT).  More  recent  references  designate  it  as  Coordinated  Univer¬ 
sal  Time  (UTC)  instead  of  GMT.  The  time  zones  advance  from  Greenwich  in  an  easterly  direction  (Figure  15.1). 
However,  at  the  international  dateline  (about  the  midpoint  around  the  world  from  Greenwich),  you  subtract  the 
time  zone  from  GMT.  To  prevent  confusion  between  a.m.  and  p.m.,  times  are  often  given  using  a  24-hour  clock. 
For  example,  midnight  is  indicated  as  00:00,  noon  is  12:00  and  1  p.m.  is  13:00. 

Example:  Conference  Call  between  Toronto  and  Paris 

A  project  manager  for  a  software  development  project  in  Toronto  is  five  time  zones  west  of  the  reference  zone, 
so  the  time  is  given  as  UTC-5  (or  GMT-5).  If  it  is  noon  in  the  reference  zone,  it  is  7  a.m.  (five  hours  earlier)  in 
Toronto.  The  manager  would  like  to  contact  a  project  team  member  in  Paris,  France.  Paris  is  one  time  zone  east 
of  the  reference  zone  (UTC+1  or  GMT+1).  If  it  is  noon  (12:00)  in  the  reference  zone,  it  is  1  p.m.  (13:00)  in  Paris. 
This  means  that  there  is  a  six-hour  difference  between  Toronto  and  Paris.  If  the  project  manager  waits  until  after 
lunch  to  place  the  call  (1  p.m.  in  Toronto),  it  will  be  too  late  in  the  day  in  Paris  (7  p.m.)  to  reach  someone. 

Asynchronous  Communications 

Getting  a  team  together  at  the  same  time  can  be  a  challenge — especially  if  they  are  spread  out  across  time  zones. 
Many  types  of  communication  do  not  require  that  the  parties  are  present  at  the  same  time.  This  type  of  communi¬ 
cation  is  asynchronous.  There  are  several  choices  of  asynchronous  communications. 

Mail  and  Package  Delivery 

Many  companies  prefer  that  final  contracts  are  personally  signed  by  an  authorized  representative  of  each  party 
to  the  agreement.  If  several  signatures  are  required,  this  can  take  weeks  to  get  all  the  signatures  if  the  contracts 
are  transferred  by  a  postal  service.  If  this  process  is  holding  up  the  start  of  the  project,  you  can  use  an  overnight 
delivery  service  to  minimize  the  time  spent  transferring  the  documents. 
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Fax 

Fax  machines  have  been  around  a  long  time  and  enjoy  a  high  level  of  trust  for  transmitting  documents  accurately. 
Although  it  might  seem  archaic  to  still  use  fax  transmissions,  in  many  countries  a  fax  of  a  signed  contract  is  legal, 
but  a  computer-scanned  image  is  not. 

Email 

Electronic  mail  (email)  is  widely  used  to  coordinate  projects  and  to  communicate  between  team  members.  It  has 
several  valuable  characteristics  for  project  management: 

•  Information  can  be  sent  to  a  list  of  team  members. 

•  Messages  can  be  saved  to  document  the  process  in  case  of  a  misunderstanding  or  miscommunication. 

•  Files  can  be  attached  and  distributed. 

Project  Blog 

A  blog  is  an  online  journal  that  can  be  private,  shared  by  invitation,  or  made  available  to  the  world.  Some  project 
managers  keep  a  journal  in  which  they  summarize  the  day’s  challenges  and  triumphs  and  the  decisions  they  made. 
They  return  to  this  journal  at  a  later  date  to  review  their  decision-making  process  after  the  results  of  those  deci¬ 
sions  are  known  to  see  if  they  can  learn  from  their  mistakes.  Many  decisions  in  project  management  are  made  with 
incomplete  knowledge,  and  reflecting  on  previous  decisions  to  develop  this  decision-making  skill  is  important  to 
growth  as  a  project  manager. 

Really  Simple  Syndication  (RSS) 

Some  projects  are  directly  affected  by  external  factors  such  as  political  elections,  economic  trends,  corporate 
mergers,  technological  or  scientific  breakthroughs,  or  weather.  To  keep  informed  about  these  factors,  you  can  sub¬ 
scribe  to  online  news  sources.  A  technology  that  facilitates  this  process  is  Really  Simple  Syndication  (RSS).  Web 
pages  with  RSS  news  feeds  have  labeled  links. 

If  the  user  clicks  on  the  RSS  feed,  news  from  the  website  is  automatically  sent  to  the  user’s  news  reader,  such  as 
Google  Reader.  The  news  reader  can  be  set  to  filter  the  news  for  key  words  to  limit  the  stories  to  those  that  are 
relevant  to  the  project. 

Assessing  New  Communication  Technologies 

New  technologies  for  communicating  electronically  appear  with  increasing  frequency.  Using  a  new  technology 
that  is  unfamiliar  to  the  team  increases  the  technology  complexity,  which  can  cause  delays  and  increase  costs.  To 
decide  if  a  new  technology  should  be  included  in  a  communications  plan,  seek  answers  to  the  following  questions 
(Business  Dictionary): 

•  Does  the  new  communication  technology  provide  a  competitive  advantage  for  the  project  by  reducing  cost, 
saving  time,  or  preventing  mistakes? 

•  Does  the  project  team  have  the  expertise  to  learn  the  new  technology  quickly? 


152  •  PROJECT  MANAGEMENT 


•  Does  the  company  offer  support  such  as  a  help  desk  and  equipment  service  for  new  communication  tech¬ 
nology? 

•  What  is  the  cost  of  training  and  implementation  in  terms  of  time  as  well  as  money 


Communication  Plan  Template 

So  how  do  you  create  a  communication  plan? 

1.  Identify  your  stakeholders  (to  whom) 

2.  Identify  stakeholder  expectations  (why) 

3.  Identify  communication  necessary  to  satisfy  stakeholder  expectations  and  keep  them  informed  (what) 

4.  Identify  time-frame  and/or  frequency  of  communication  messages  (when) 

5.  Identify  how  the  message  will  be  communicated  (the  stakeholder’s  preferred  method)  (how) 

6.  Identify  who  will  communication  each  message  (who) 

7.  Document  items  -  templates,  formats,  or  documents  the  project  must  use  for  communicating. 

Figure  15.2  shows  a  communication  plan  template. 


Figure  15.2  Communications  Plan  Template 

(http://inte5160.wikispaces.com/Communication+Plans)  used 
under  CC-BY-SA  license  (http://creativecommons.org/licenses/ 
by-sa/3.0/) 
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16.  Risk  Management  Planning 


ADRIENNE  WATT 


Even  the  most  carefully  planned  project  can  run  into  trouble.  No  matter  how  well  you  plan,  your  project  can 
always  encounter  unexpected  problems.  Team  members  get  sick  or  quit,  resources  that  you  were  depending  on 
turn  out  to  be  unavailable,  even  the  weather  can  throw  you  for  a  loop  (e.g.,  a  snowstorm).  So  does  that  mean 
that  you’re  helpless  against  unknown  problems?  No!  You  can  use  risk  planning  to  identify  potential  problems  that 
could  cause  trouble  for  your  project,  analyze  how  likely  they  are  to  occur,  take  action  to  prevent  the  risks  you  can 
avoid,  and  minimize  the  ones  that  you  can’t. 

A  risk  is  any  uncertain  event  or  condition  that  might  affect  your  project.  Not  all  risks  are  negative.  Some  events 
(like  finding  an  easier  way  to  do  an  activity)  or  conditions  (like  lower  prices  for  certain  materials)  can  help  your 
project.  When  this  happens,  we  call  it  an  opportunity;  but  it’s  still  handled  just  like  a  risk. 

There  are  no  guarantees  on  any  project.  Even  the  simplest  activity  can  turn  into  unexpected  problems.  Anything 
that  might  occur  to  change  the  outcome  of  a  project  activity,  we  call  that  a  risk.  A  risk  can  be  an  event  (like  a 
snowstorm)  or  it  can  be  a  condition  (like  an  important  part  being  unavailable).  Either  way,  it’s  something  that 
may  or  may  not  happen  . .  .but  if  it  does,  then  it  will  force  you  to  change  the  way  you  and  your  team  work  on  the 
project. 

If  your  project  requires  that  you  stand  on  the  edge  of  a  cliff,  then  there’s  a  risk  that  you  could  fall.  If  it’s  very 
windy  out  or  if  the  ground  is  slippery  and  uneven,  then  falling  is  more  likely  (Figure  16.1). 


Figure  16.1  Risk  Management  Options 

Illustration  from  Barron  &  Barron  Project  Management  for 

Scientists  and  Engineers,  http://cnx.Org/content/collll20/l.4/ 


When  you’re  planning  your  project,  risks  are  still  uncertain:  they  haven’t  happened  yet.  But  eventually,  some  of 
the  risks  that  you  plan  for  do  happen,  and  that’s  when  you  have  to  deal  with  them.  There  are  four  basic  ways  to 
handle  a  risk. 
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1.  Avoid:  The  best  thing  you  can  do  with  a  risk  is  avoid  it.  If  you  can  prevent  it  from  happening,  it  defi¬ 
nitely  won’t  hurt  your  project.  The  easiest  way  to  avoid  this  risk  is  to  walk  away  from  the  cliff,  but  that  may 
not  be  an  option  on  this  project. 

2.  Mitigate:  If  you  can’t  avoid  the  risk,  you  can  mitigate  it.  This  means  taking  some  sort  of  action  that  will 
cause  it  to  do  as  little  damage  to  your  project  as  possible. 

3.  Transfer:  One  effective  way  to  deal  with  a  risk  is  to  pay  someone  else  to  accept  it  for  you.  The  most  com¬ 
mon  way  to  do  this  is  to  buy  insurance. 

4.  Accept:  When  you  can’t  avoid,  mitigate,  or  transfer  a  risk,  then  you  have  to  accept  it.  But  even  when  you 
accept  a  risk,  at  least  you’ve  looked  at  the  alternatives  and  you  know  what  will  happen  if  it  occurs.  If  you 
can’t  avoid  the  risk,  and  there’s  nothing  you  can  do  to  reduce  its  impact,  then  accepting  it  is  your  only 
choice. 

By  the  time  a  risk  actually  occurs  on  your  project,  it’s  too  late  to  do  anything  about  it.  That’s  why  you  need  to 
plan  for  risks  from  the  beginning  and  keep  coming  back  to  do  more  planning  throughout  the  project. 

The  risk  management  plan  tells  you  how  you’re  going  to  handle  risk  in  your  project.  It  documents  how  you’ll 
assess  risk,  who  is  responsible  for  doing  it,  and  how  often  you’ll  do  risk  planning  (since  you’ll  have  to  meet  about 
risk  planning  with  your  team  throughout  the  project). 

Some  risks  are  technical,  like  a  component  that  might  turn  out  to  be  difficult  to  use.  Others  are  external,  like 
changes  in  the  market  or  even  problems  with  the  weather. 

It’s  important  to  come  up  with  guidelines  to  help  you  figure  out  how  big  a  risk’s  potential  impact  could  be.  The 
impact  tells  you  how  much  damage  the  risk  would  cause  to  your  project.  Many  projects  classify  impact  on  a  scale 
from  minimal  to  severe,  or  from  very  low  to  very  high.  Your  risk  management  plan  should  give  you  a  scale  to 
help  figure  out  the  probability  of  the  risk.  Some  risks  are  very  likely;  others  aren’t. 


Risk  Management  Process 

Managing  risks  on  projects  is  a  process  that  includes  risk  assessment  and  a  mitigation  strategy  for  those  risks.  Risk 
assessment  includes  both  the  identification  of  potential  risk  and  the  evaluation  of  the  potential  impact  of  the  risk. 
A  risk  mitigation  plan  is  designed  to  eliminate  or  minimize  the  impact  of  the  risk  events — occurrences  that  have 
a  negative  impact  on  the  project.  Identifying  risk  is  both  a  creative  and  a  disciplined  process.  The  creative  process 
includes  brainstorming  sessions  where  the  team  is  asked  to  create  a  list  of  everything  that  could  go  wrong.  All 
ideas  are  welcome  at  this  stage  with  the  evaluation  of  the  ideas  coming  later. 

Risk  Identification 

A  more  disciplined  process  involves  using  checklists  of  potential  risks  and  evaluating  the  likelihood  that  those 
events  might  happen  on  the  project.  Some  companies  and  industries  develop  risk  checklists  based  on  experience 
from  past  projects.  These  checklists  can  be  helpful  to  the  project  manager  and  project  team  in  identifying  both  spe¬ 
cific  risks  on  the  checklist  and  expanding  the  thinking  of  the  team.  The  past  experience  of  the  project  team,  project 
experience  within  the  company,  and  experts  in  the  industry  can  be  valuable  resources  for  identifying  potential  risk 
on  a  project. 
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Identifying  the  sources  of  risk  by  category  is  another  method  for  exploring  potential  risk  on  a  project.  Some  exam¬ 
ples  of  categories  for  potential  risks  include  the  following: 

•  Technical 

•  Cost 

•  Schedule 

•  Client 

•  Contractual 

•  Weather 

•  Financial 

•  Political 

•  Environmental 

•  People 

You  can  use  the  same  framework  as  the  work  breakdown  structure  (WBS)  for  developing  a  risk  breakdown 
structure  (RBS).  A  risk  breakdown  structure  organizes  the  risks  that  have  been  identified  into  categories  using 
a  table  with  increasing  levels  of  detail  to  the  right.  The  people  category  can  be  subdivided  into  different  types  of 
risks  associated  with  the  people.  Examples  of  people  risks  include  the  risk  of  not  finding  people  with  the  skills 
needed  to  execute  the  project  or  the  sudden  unavailability  of  key  people  on  the  project. 

Example:  Risks  in  John's  Move 

In  John’s  move,  John  makes  a  list  of  things  that  might  go  wrong  with  his  project  and  uses  his  work  breakdown 
structure  as  a  guide.  A  partial  list  for  the  planning  portion  of  the  RBS  is  shown  in  Figure  16.2. 


Figure  16.2  Risk  Breakdown  Structure  (RBS) 
Source:  http://pm4id.org/ll/2/ 


The  result  is  a  clearer  understanding  of  where  risks  are  most  concentrated.  This  approach  helps  the  project  team 
identify  known  risks,  but  can  be  restrictive  and  less  creative  in  identifying  unknown  risks  and  risks  not  easily 
found  inside  the  WBS. 

Risk  Evaluation 

After  the  potential  risks  have  been  identified,  the  project  team  then  evaluates  each  risk  based  on  the  probability 
that  a  risk  event  will  occur  and  the  potential  loss  associated  with  it.  Not  all  risks  are  equal.  Some  risk  events  are 
more  likely  to  happen  than  others,  and  the  cost  of  a  risk  can  vary  greatly.  Evaluating  the  risk  for  probability  of 
occurrence  and  the  severity  or  the  potential  loss  to  the  project  is  the  next  step  in  the  risk  management  process. 
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Having  criteria  to  determine  high-impact  risks  can  help  narrow  the  focus  on  a  few  critical  risks  that  require  miti¬ 
gation.  For  example,  suppose  high-impact  risks  are  those  that  could  increase  the  project  costs  by  5%  of  the  con¬ 
ceptual  budget  or  2%  of  the  detailed  budget.  Only  a  few  potential  risk  events  meet  these  criteria.  These  are  the 
critical  few  potential  risk  events  that  the  project  management  team  should  focus  on  when  developing  a  project  risk 
mitigation  or  management  plan.  Risk  evaluation  is  about  developing  an  understanding  of  which  potential  risks 
have  the  greatest  possibility  of  occurring  and  can  have  the  greatest  negative  impact  on  the  project  (Figure  16.3). 
These  become  the  critical  few. 


Figure  16.3  Risk  and  Impact 
Source:  http://pm4id.Org/ll/2/ 


There  is  a  positive  correlation — both  increase  or  decrease  together — between  project  risk  and  project  complexity. 
A  project  with  new  and  emerging  technology  will  have  a  high-complexity  rating  and  a  correspondingly  high  risk. 
The  project  management  team  will  assign  the  appropriate  resources  to  the  technology  managers  to  ensure  the 
accomplishment  of  project  goals.  The  more  complex  the  technology,  the  more  resources  the  technology  manager 
typically  needs  to  meet  project  goals,  and  each  of  those  resources  could  face  unexpected  problems. 

Risk  evaluation  often  occurs  in  a  workshop  setting.  Building  on  the  identification  of  the  risks,  each  risk  event  is 
analyzed  to  determine  the  likelihood  of  occurrence  and  the  potential  cost  if  it  did  occur.  The  likelihood  and  impact 
are  both  rated  as  high,  medium,  or  low.  A  risk  mitigation  plan  addresses  the  items  that  have  high  ratings  on  both 
factors — likelihood  and  impact. 

Example:  Risk  Analysis  of  Equipment  Delivery 

A  project  team  analyzed  the  risk  of  some  important  equipment  not  arriving  at  the  project  on  time.  The  team  iden¬ 
tified  three  pieces  of  equipment  that  were  critical  to  the  project  and  would  significantly  increase  costs  if  they  were 
late  in  arriving.  One  of  the  vendors,  who  was  selected  to  deliver  an  important  piece  of  equipment,  had  a  history 
of  being  late  on  other  projects.  The  vendor  was  good  and  often  took  on  more  work  than  it  could  deliver  on  time. 
This  risk  event  (the  identified  equipment  arriving  late)  was  rated  as  high  likelihood  with  a  high  impact.  The  other 
two  pieces  of  equipment  were  potentially  a  high  impact  on  the  project  but  with  a  low  probability  of  occurring. 

Not  all  project  managers  conduct  a  formal  risk  assessment  on  a  project.  One  reason,  as  found  by  David  Parker 
and  Alison  Mobey  in  their  phenomenological  study  of  project  managers,  was  a  low  understanding  of  the  tools 
and  benefits  of  a  structured  analysis  of  project  risks  (2004).  The  lack  of  formal  risk  management  tools  was  also 
seen  as  a  barrier  to  implementing  a  risk  management  program.  Additionally,  the  project  manager’s  personality 
and  management  style  play  into  risk  preparation  levels.  Some  project  managers  are  more  proactive  and  develop 
elaborate  risk  management  programs  for  their  projects.  Other  managers  are  reactive  and  are  more  confident  in 
their  ability  to  handle  unexpected  events  when  they  occur.  Yet  others  are  risk  averse,  and  prefer  to  be  optimistic 
and  not  consider  risks  or  avoid  taking  risks  whenever  possible. 

On  projects  with  a  low-complexity  profile,  the  project  manager  may  informally  track  items  that  may  be  considered 
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risk  items.  On  more  complex  projects,  the  project  management  team  may  develop  a  list  of  items  perceived  to  be 
higher  risk  and  track  them  during  project  reviews.  On  projects  of  even  greater  complexity,  the  process  for  eval¬ 
uating  risk  is  more  formal  with  a  risk  assessment  meeting  or  series  of  meetings  during  the  life  of  the  project  to 
assess  risks  at  different  phases  of  the  project.  On  highly  complex  projects,  an  outside  expert  may  be  included  in 
the  risk  assessment  process,  and  the  risk  assessment  plan  may  take  a  more  prominent  place  in  the  project  imple¬ 
mentation  plan. 

On  complex  projects,  statistical  models  are  sometimes  used  to  evaluate  risk  because  there  are  too  many  different 
possible  combinations  of  risks  to  calculate  them  one  at  a  time.  One  example  of  the  statistical  model  used  on  pro¬ 
jects  is  the  Monte  Carlo  simulation,  which  simulates  a  possible  range  of  outcomes  by  trying  many  different  com¬ 
binations  of  risks  based  on  their  likelihood.  The  output  from  a  Monte  Carlo  simulation  provides  the  project  team 
with  the  probability  of  an  event  occurring  within  a  range  and  for  combinations  of  events.  For  example,  the  typical 
output  from  a  Monte  Carlo  simulation  may  indicate  a  10%  chance  that  one  of  the  three  important  pieces  of  equip¬ 
ment  will  be  late  and  that  the  weather  will  also  be  unusually  bad  after  the  equipment  arrives. 

Risk  Mitigation 

After  the  risk  has  been  identified  and  evaluated,  the  project  team  develops  a  risk  mitigation  plan,  which  is  a  plan 
to  reduce  the  impact  of  an  unexpected  event.  The  project  team  mitigates  risks  in  various  ways: 

•  Risk  avoidance 

•  Risk  sharing 

•  Risk  reduction 

•  Risk  transfer 

Each  of  these  mitigation  techniques  can  be  an  effective  tool  in  reducing  individual  risks  and  the  risk  profile  of 
the  project.  The  risk  mitigation  plan  captures  the  risk  mitigation  approach  for  each  identified  risk  event  and  the 
actions  the  project  management  team  will  take  to  reduce  or  eliminate  the  risk. 

Risk  avoidance  usually  involves  developing  an  alternative  strategy  that  has  a  higher  probability  of  success  but 
usually  at  a  higher  cost  associated  with  accomplishing  a  project  task.  A  common  risk  avoidance  technique  is  to  use 
proven  and  existing  technologies  rather  than  adopt  new  techniques,  even  though  the  new  techniques  may  show 
promise  of  better  performance  or  lower  costs.  A  project  team  may  choose  a  vendor  with  a  proven  track  record 
over  a  new  vendor  that  is  providing  significant  price  incentives  to  avoid  the  risk  of  working  with  a  new  vendor. 
The  project  team  that  requires  drug  testing  for  team  members  is  practicing  risk  avoidance  by  avoiding  damage 
done  by  someone  under  the  influence  of  drugs. 

Risk  sharing  involves  partnering  with  others  to  share  responsibility  for  the  risky  activities.  Many  organizations 
that  work  on  international  projects  will  reduce  political,  legal,  labor,  and  others  risk  types  associated  with  inter¬ 
national  projects  by  developing  a  joint  venture  with  a  company  located  in  that  country.  Partnering  with  another 
company  to  share  the  risk  associated  with  a  portion  of  the  project  is  advantageous  when  the  other  company  has 
expertise  and  experience  the  project  team  does  not  have.  If  a  risk  event  does  occur,  then  the  partnering  company 
absorbs  some  or  all  of  the  negative  impact  of  the  event.  The  company  will  also  derive  some  of  the  profit  or  benefit 
gained  by  a  successful  project. 
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Risk  reduction  is  an  investment  of  funds  to  reduce  the  risk  on  a  project.  On  international  projects,  companies 
will  often  purchase  the  guarantee  of  a  currency  rate  to  reduce  the  risk  associated  with  fluctuations  in  the  currency 
exchange  rate.  A  project  manager  may  hire  an  expert  to  review  the  technical  plans  or  the  cost  estimate  on  a  project 
to  increase  the  confidence  in  that  plan  and  reduce  the  project  risk.  Assigning  highly  skilled  project  personnel  to 
manage  the  high-risk  activities  is  another  risk-reduction  method.  Experts  managing  a  high-risk  activity  can  often 
predict  problems  and  find  solutions  that  prevent  the  activities  from  having  a  negative  impact  on  the  project.  Some 
companies  reduce  risk  by  forbidding  key  executives  or  technology  experts  to  ride  on  the  same  airplane. 

Risk  transfer  is  a  risk  reduction  method  that  shifts  the  risk  from  the  project  to  another  party.  The  purchase  of 
insurance  on  certain  items  is  a  risk-transfer  method.  The  risk  is  transferred  from  the  project  to  the  insurance  com¬ 
pany.  A  construction  project  in  the  Caribbean  may  purchase  hurricane  insurance  that  would  cover  the  cost  of  a 
hurricane  damaging  the  construction  site.  The  purchase  of  insurance  is  usually  in  areas  outside  the  control  of  the 
project  team.  Weather,  political  unrest,  and  labor  strikes  are  examples  of  events  that  can  significantly  impact  the 
project  and  that  are  outside  the  control  of  the  project  team. 

Contingency  Plan 

The  project  risk  plan  balances  the  investment  of  the  mitigation  against  the  benefit  for  the  project.  The  project  team 
often  develops  an  alternative  method  for  accomplishing  a  project  goal  when  a  risk  event  has  been  identified  that 
may  frustrate  the  accomplishment  of  that  goal.  These  plans  are  called  contingency  plans.  The  risk  of  a  truck  dri¬ 
vers’  strike  may  be  mitigated  with  a  contingency  plan  that  uses  a  train  to  transport  the  needed  equipment  for  the 
project.  If  a  critical  piece  of  equipment  is  late,  the  impact  on  the  schedule  can  be  mitigated  by  making  changes  to 
the  schedule  to  accommodate  a  late  equipment  delivery. 

Contingency  funds  are  funds  set  aside  by  the  project  team  to  address  unforeseen  events  that  cause  the  project  costs 
to  increase.  Projects  with  a  high-risk  profile  will  typically  have  a  large  contingency  budget.  Although  the  amount 
of  contingency  allocated  in  the  project  budget  is  a  function  of  the  risks  identified  in  the  risk  analysis  process,  con¬ 
tingency  is  typically  managed  as  one  line  item  in  the  project  budget. 

Some  project  managers  allocate  the  contingency  budget  to  the  items  in  the  budget  that  have  high  risk  rather  than 
developing  one  line  item  in  the  budget  for  contingencies.  This  approach  allows  the  project  team  to  track  the  use 
of  contingency  against  the  risk  plan.  This  approach  also  allocates  the  responsibility  to  manage  the  risk  budget  to 
the  managers  responsible  for  those  line  items.  The  availability  of  contingency  funds  in  the  line  item  budget  may 
also  increase  the  use  of  contingency  funds  to  solve  problems  rather  than  finding  alternative,  less  costly  solutions. 
Most  project  managers,  especially  on  more  complex  projects,  manage  contingency  funds  at  the  project  level,  with 
approval  of  the  project  manager  required  before  contingency  funds  can  be  used. 


Project  Risk  by  Phases 

Project  risk  is  dealt  with  in  different  ways  depending  on  the  phase  of  the  project. 


Initiation 

Risk  is  associated  with  things  that  are  unknown.  More  things  are  unknown  at  the  beginning  of  a  project,  but  risk 
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must  be  considered  in  the  initiation  phase  and  weighed  against  the  potential  benefit  of  the  project’s  success  in 
order  to  decide  if  the  project  should  be  chosen. 

Example:  Risks  by  Phase  in  John's  Move 

In  the  initiation  phase  of  his  move,  John  considers  the  risk  of  events  that  could  affect  the  whole  project.  Lets 
assume  that  John’s  move  is  not  just  about  changing  jobs,  but  also  a  change  of  cities.  This  would  certainly  incur 
more  risks  for  the  project.  He  identifies  the  following  risks  during  the  initiation  phase  that  might  have  a  high 
impact  and  rates  the  likelihood  of  their  happening  from  low  to  high. 

J.  His  new  employer  might  change  his  mind  and  take  back  the  job  offer  after  he’s  given  notice  at  his  old 
job:  Low. 

2.  The  current  tenants  of  his  apartment  might  not  move  out  in  time  for  him  to  move  in  by  the  first  day  of 
work  at  the  new  job:  Medium. 

3.  The  movers  might  lose  his  furniture:  Low. 

4.  The  movers  might  be  more  than  a  week  late  delivering  his  furniture:  Medium. 

5.  He  might  get  in  an  accident  driving  from  Chicago  to  Atlanta  and  miss  starting  his  job:  Low. 

John  considers  how  to  mitigate  each  of  the  risks. 

J.  During  his  job  hunt,  John  had  more  than  one  offer,  and  he  is  confident  that  he  could  get  another  job,  but 
he  might  lose  deposit  money  on  the  apartment  and  the  mover.  He  would  also  lose  wages  during  the  time  it 
took  to  find  the  other  job.  To  mitigate  the  risk  of  his  new  employer  changing  his  mind,  John  makes  sure  that 
he  keeps  his  relationships  with  his  alternate  employers  cordial  and  writes  to  each  of  them  thanking  for  their 
consideration  in  his  recent  interviews. 

2.  John  checks  the  market  in  Atlanta  to  determine  the  weekly  cost  and  availability  of  extended-stay  motels. 

3.  John  checks  the  mover’s  contract  to  confirm  that  they  carry  insurance  against  lost  items,  but  they  require 
the  owner  to  provide  a  detailed  list  with  value  estimates  and  they  limit  the  maximum  total  value.  John 
decides  to  go  through  his  apartment  with  his  digital  camera  and  take  pictures  of  all  of  his  possessions  that 
will  be  shipped  by  truck  and  to  keep  the  camera  with  him  during  the  move  so  he  has  a  visual  record  and 
won’t  have  to  rely  on  his  memory  to  make  a  list.  He  seals  and  numbers  the  boxes  so  he  can  tell  if  a  box  is 
missing. 

4.  If  the  movers  are  late,  John  can  use  his  research  on  extended-stay  motels  to  calculate  how  much  it  would 
cost.  He  checks  the  moving  company’s  contract  to  see  if  they  compensate  the  owner  for  late  delivery,  and 
he  finds  that  they  do  not. 

5.  John  checks  the  estimated  driving  time  from  Chicago  to  Atlanta  using  an  Internet  mapping  service  and 
gets  an  estimate  of  11  hours  of  driving  time.  He  decides  that  it  would  be  too  risky  to  attempt  to  make  the 
drive  by  himself  in  one  day,  especially  if  he  didn’t  leave  until  after  the  truck  was  packed.  John  plans  to 
spend  one  night  on  the  road  in  a  motel  to  reduce  the  risk  of  an  accident  caused  by  driving  while  too  tired. 

John  concludes  that  the  medium-risks  can  be  mitigated  and  the  costs  from  the  mitigation  would  be  acceptable  in 
order  to  get  a  new  job. 
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Planning  Phase 

Once  the  project  is  approved  and  it  moves  into  the  planning  stage,  risks  are  identified  with  each  major  group  of 
activities.  A  risk  breakdown  structure  (RBS)  can  be  used  to  identify  increasing  levels  of  detailed  risk  analysis. 


Example:  Risk  Breakdown  Structure  for  John's  Move 


Figure  16.4  Risk  Breakdown  Structure  (RBS)  for  Packing  John’s 
Apartment 

Source:  http://pm4id.0rg/ll/3/ 


John  decides  to  ask  Dion  and  Carlita  for  their  help  during  their  first  planning  meeting  to  identify  risks,  rate  their 
impact  and  likelihood,  and  suggest  mitigation  plans.  They  concentrate  on  the  packing  phase  of  the  move.  They 
fill  out  a  table  of  risks,  as  shown  in  Figure  16.4. 

Implementation  Phase 

As  the  project  progresses  and  more  information  becomes  available  to  the  project  team,  the  total  risk  on  the  project 
typically  reduces,  as  activities  are  performed  without  loss.  The  risk  plan  needs  to  be  updated  with  new  information 
and  risks  checked  off  that  are  related  to  activities  that  have  been  performed. 

Understanding  where  the  risks  occur  on  the  project  is  important  information  for  managing  the  contingency  budget 
and  managing  cash  reserves.  Most  organizations  develop  a  plan  for  financing  the  project  from  existing  organiza¬ 
tional  resources,  including  financing  the  project  through  a  variety  of  financial  instruments.  In  most  cases,  there  is 
a  cost  to  the  organization  to  keep  these  funds  available  to  the  project,  including  the  contingency  budget.  As  the 
risks  decrease  over  the  length  of  the  project,  if  the  contingency  is  not  used,  then  the  funds  set  aside  by  the  organi¬ 
zation  can  be  used  for  other  purposes. 

To  determine  the  amount  of  contingency  that  can  be  released,  the  project  team  will  conduct  another  risk  evaluation 
and  determine  the  amount  of  risk  remaining  on  the  project.  If  the  risk  profile  is  lower,  the  project  team  may  release 
contingency  funds  back  to  the  parent  organization.  If  additional  risks  are  uncovered,  a  new  mitigation  plan  is 
developed  including  the  possible  addition  of  contingency  funds. 

Closeout  Phase 

During  the  closeout  phase,  agreements  for  risk  sharing  and  risk  transfer  need  to  be  concluded  and  the  risk  break¬ 
down  structure  examined  to  be  sure  all  the  risk  events  have  been  avoided  or  mitigated.  The  final  estimate  of  loss 
due  to  risk  can  be  made  and  recorded  as  part  of  the  project  documentation.  If  a  Monte  Carlo  simulation  was  done, 
the  result  can  be  compared  to  the  predicted  result. 


16.  RISK  MANAGEMENT  PLANNING  •  161 


Example:  Risk  Closeout  on  John's  Move 

To  close  out  the  risk  mitigation  plan  for  his  move,  John  examines  the  risk  breakdown  structure  and  risk  mitigation 
plan  for  items  that  need  to  be  finalized.  He  makes  a  checklist  to  be  sure  all  the  risk  mitigation  plans  are  completed, 
as  shown  in  Figure  16.5.  Risk  is  not  allocated  evenly  over  the  life  of  the  project.  On  projects  with  a  high  degree 
of  new  technology,  the  majority  of  the  risks  may  be  in  the  early  phases  of  the  project.  On  projects  with  a  large 
equipment  budget,  the  largest  amount  of  risk  may  be  during  the  procurement  of  the  equipment.  On  global  projects 
with  a  large  amount  of  political  risk,  the  highest  portion  of  risk  may  be  toward  the  end  of  the  project. 


Figure  16.5  Closeout  of  Risk  Mitigation  Plan  for  John’s  Move 
Source:  http://pm4id.Org/ll/3/ 
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ADRIENNE  WATT 


After  you  have  carefully  planned  your  project,  you  will  be  ready  to  start  the  project  implementation  phase,  the 
third  phase  of  the  project  management  life  cycle.  The  implementation  phase  involves  putting  the  project  plan  into 
action.  It’s  here  that  the  project  manager  will  coordinate  and  direct  project  resources  to  meet  the  objectives  of  the 
project  plan.  As  the  project  unfolds,  it’s  the  project  manager’s  job  to  direct  and  manage  each  activity,  every  step 
of  the  way.  That’s  what  happens  in  the  implementation  phase  of  the  project  life  cycle:  you  follow  the  plan  you’ve 
put  together  and  handle  any  problems  that  come  up. 

The  implementation  phase  is  where  you  and  your  project  team  actually  do  the  project  work  to  produce  the  deliver¬ 
ables.  The  word  “deliverable”  means  anything  your  project  delivers.  The  deliverables  for  your  project  include  all 
of  the  products  or  services  that  you  and  your  team  are  performing  for  the  client,  customer,  or  sponsor,  including 
all  the  project  management  documents  that  you  put  together. 

The  steps  undertaken  to  build  each  deliverable  will  vary  depending  on  the  type  of  project  you  are  undertaking,  and 
cannot  therefore  be  described  here  in  any  real  detail.  For  instance  engineering  and  telecommunications  projects 
will  focus  on  using  equipment,  resources,  and  materials  to  construct  each  project  deliverable,  whereas  computer 
software  projects  may  require  the  development  and  implementation  of  software  code  routines  to  produce  each 
project  deliverable.  The  activities  required  to  build  each  deliverable  will  be  clearly  specified  within  the  project 
requirements  document  and  project  plan. 

Your  job  as  project  manager  is  to  direct  the  work,  but  you  need  to  do  more  than  deliver  the  results.  You  also  need 
to  keep  track  of  how  well  your  team  performs.  The  implementation  phase  keeps  the  project  plan  on  track  with 
careful  monitoring  and  control  processes  to  ensure  the  final  deliverable  meets  the  acceptance  criteria  set  by  the 
customer.  This  phase  is  typically  where  approved  changes  are  implemented. 

Most  often,  changes  are  identified  by  looking  at  performance  and  quality  control  data.  Routine  performance  and 
quality  control  measurements  should  be  evaluated  on  a  regular  basis  throughout  the  implementation  phase.  Gath¬ 
ering  reports  on  those  measurements  will  help  you  determine  where  the  problem  is  and  recommend  changes  to  fix 
it. 


162 


ADRIENNE  WATT  •  163 


Change  Control 

When  you  find  a  problem,  you  can’t  just  make  a  change,  because  it  may  be  too  expensive  or  take  too  long  to  do. 
You  will  need  to  look  at  how  it  affects  the  triple  constraint  (time,  cost,  scope)  and  how  it  impacts  project  quality. 
You  will  then  have  to  figure  out  if  it  is  worth  making  the  change.  If  you  evaluate  the  impact  of  the  change  and  find 
that  it  won’t  have  an  impact  on  the  project  triple  constraint,  then  you  can  make  the  change  without  going  through 
change  control.  Change  control  is  a  set  of  procedures  that  lets  you  make  changes  in  an  organized  way. 

Any  time  you  need  to  make  a  change  to  your  plan,  you  must  start  with  a  change  request.  This  is  a  document  that 
either  you  or  the  person  making  the  request  must  complete.  Any  change  to  your  project  must  be  documented  so 
you  can  figure  out  what  needs  to  be  done,  by  when,  and  by  whom. 

Once  the  change  request  is  documented,  it  is  submitted  to  a  change  control  board.  A  change  control  board  is  a 
group  of  people  who  consider  changes  for  approval.  Not  every  change  control  system  has  a  board  but  most  do.  The 
change  request  could  also  be  submitted  to  the  project  sponsor  or  management  for  review  and  approval.  Putting 
the  recommended  changes  through  change  control  will  help  you  evaluate  the  impact  and  update  all  the  necessary 
documents.  Not  all  changes  are  approved,  but  if  the  changes  are  approved,  you  send  them  back  to  the  team  to  put 
them  in  place. 

The  implementation  phase  uses  the  most  project  time  and  resources,  and  as  a  result,  costs  are  usually  the  highest 
during  this  phase.  Project  managers  also  experience  the  greatest  conflicts  over  schedules  in  this  phase.  You  may 
find  as  you  are  monitoring  your  project  that  the  actual  time  it  is  taking  to  do  the  scheduled  work  is  longer  than  the 
amount  of  time  planned. 

When  you  absolutely  have  to  meet  the  date  and  you  are  running  behind,  you  can  sometimes  find  ways  to  do  activ¬ 
ities  more  quickly  by  adding  more  resources  to  critical  path  tasks.  That’s  called  crashing.  Crashing  the  schedule 
means  adding  resources  or  moving  them  around  to  to  bring  the  project  back  into  line  with  the  schedule.  Crashing 
always  costs  more  and  doesn’t  always  work.  There’s  no  way  to  crash  a  schedule  without  raising  the  overall  cost  of 
the  project.  So,  if  the  budget  is  fixed  and  you  don’t  have  any  extra  money  to  spend,  you  can’t  use  this  technique. 

Sometimes  you’ve  got  two  activities  planned  to  occur  in  sequence,  but  you  can  actually  do  them  at  the  same  time. 
This  is  called  fast  tracking  the  project.  On  a  software  project,  you  might  do  both  your  user  acceptance  testing 
(UAT)  and  your  functional  testing  at  the  same  time,  for  example.  This  is  pretty  risky.  There’s  a  good  chance  you 
might  need  to  redo  some  of  the  work  you  have  done  concurrently.  Crashing  and  fast  tracking  are  schedule  com¬ 
pression  tools.  Managing  a  schedule  change  means  keeping  all  of  your  schedule  documents  up  to  date.  That  way, 
you  will  always  be  comparing  your  results  to  the  correct  plan. 

After  the  deliverables  have  been  physically  constructed  and  accepted  by  the  customer,  a  phase  review  is  carried 
out  to  determine  whether  the  project  is  complete  and  ready  for  closure. 
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18.  Project  Completion 
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Every  project  needs  to  end  and  that’s  what  project  completion  is  all  about  in  the  last  phase  of  the  project  life  cycle. 
The  whole  point  of  the  project  is  to  deliver  what  you  promised.  By  delivering  everything  you  said  you  would,  you 
make  sure  that  all  stakeholders  are  satisfied  and  all  acceptance  criteria  have  been  met.  Once  that  happens,  your 
project  can  end. 

Project  completion  is  often  the  most  neglected  phase  of  the  project  life  cycle.  Once  the  project  is  over,  it’s  easy  to 
pack  things  up,  throw  some  files  in  a  drawer,  and  start  moving  right  into  the  initiation  phase  of  the  next  project. 
Hold  on.  You’re  not  done  yet. 

The  key  activities  in  project  completion  are  gathering  project  records;  disseminating  information  to  formalize 
acceptance  of  the  product,  service,  or  project;  and  performing  project  closure.  As  the  project  manager,  you  will 
need  to  review  project  documents  to  make  certain  they  are  up-to-date.  For  example,  perhaps  some  scope  change 
requests  were  implemented  that  changed  some  of  the  characteristics  of  the  final  product.  The  project  information 
you  are  collecting  during  this  phase  should  reflect  the  characteristics  and  specifications  of  the  final  product.  Don’t 
forget  to  update  your  resource  assignments  as  well.  Some  team  members  will  have  come  and  gone  over  the  course 
of  the  project.  You  need  to  double-check  that  all  the  resources  and  their  roles  and  responsibilities  are  noted. 

Once  the  project  outcomes  are  documented,  you’ll  request  formal  acceptance  from  the  stakeholders  or  customer. 
They’re  interested  in  knowing  if  the  product  or  service  of  the  project  meets  the  objectives  the  project  set  out  to 
accomplish.  If  your  documentation  is  up-to-date,  you’ll  have  the  project  results  at  hand  to  share  with  them. 


Contract  Closure 

Contracts  come  to  a  close  just  as  projects  come  to  a  close.  Contract  closure  is  concerned  with  completing  and 
settling  the  terms  of  the  contracts  let  for  the  project.  It  supports  the  project  completion  process  because  the  con¬ 
tract  closure  process  determines  if  the  work  described  in  the  contracts  was  completed  accurately  and  satisfactorily. 
Keep  in  mind  that  not  all  projects  are  performed  under  contract  so  not  all  projects  require  the  contract  closure 
process.  Obviously,  this  process  applies  only  to  those  phases,  deliverables,  or  portions  of  the  project  that  were 
performed  under  contract. 
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Contract  closure  updates  the  project  records,  detailing  the  final  results  of  the  work  on  the  project.  Contracts  may 
have  specific  terms  or  conditions  for  completion.  You  should  be  aware  of  these  terms  or  conditions  so  that  project 
completion  isn’t  held  up  because  you  missed  an  important  detail.  If  you  are  administering  the  contract  yourself, 
be  sure  to  ask  your  procurement  department  if  there  are  any  special  conditions  that  you  should  be  aware  of  so  that 
your  project  team  doesn’t  inadvertently  delay  contract  project  closure. 

One  of  the  purposes  of  the  contract  closure  process  is  to  provide  formal  notice  to  the  seller,  usually  in  written 
form,  that  the  deliverables  are  acceptable  and  satisfactory  or  have  been  rejected.  If  the  product  or  service  does  not 
meet  the  expectations,  the  vendor  will  need  to  correct  the  problems  before  you  issue  a  formal  acceptance  notice. 
Before  the  contract  is  closed,  any  minor  items  that  need  to  be  repaired  or  completed  are  placed  on  a  punch  list, 
which  is  a  list  of  all  the  items  found  by  the  client  or  team  or  manager  that  still  remain  to  be  done.  Hopefully, 
quality  audits  have  been  performed  during  the  course  of  the  project,  and  the  vendor  was  given  the  opportunity  to 
make  corrections  earlier  in  the  process  than  the  closing  phase.  It’s  not  a  good  idea  to  wait  until  the  very  end  of 
the  project  and  then  spring  all  the  problems  and  issues  on  the  vendor  at  once.  It’s  much  more  efficient  to  discuss 
problems  with  your  vendor  as  the  project  progresses  because  it  provides  the  opportunity  for  correction  when  the 
problems  occur. 

The  project  team  will  then  work  on  all  of  the  items  on  the  punch  list,  building  a  small  schedule  to  complete  the 
remaining  work.  If  the  number  of  items  on  the  punch  list  is  too  large  or  the  amount  of  work  is  significant,  the 
project  team  continues  to  work  on  the  project.  Once  the  punch  list  becomes  smaller,  the  project  manager  begins 
closing  down  the  project,  maintaining  only  enough  staff  and  equipment  to  support  the  team  that  is  working  on  the 
punch  list. 

If  the  product  or  service  does  meet  the  project’s  expectations  and  is  acceptable,  formal  written  notice  to  the  seller 
is  required,  indicating  that  the  contract  is  complete.  This  is  the  formal  acceptance  and  closure  of  the  contract.  It’s 
your  responsibility  as  the  project  manager  to  document  the  formal  acceptance  of  the  contract.  Many  times  the 
provisions  for  formalizing  acceptance  and  closing  the  contract  are  spelled  out  in  the  contract  itself. 

If  you  have  a  procurement  department  handling  the  contract  administration,  they  will  expect  you  to  inform  them 
when  the  contract  is  complete  and  will  in  turn  follow  the  formal  procedures  to  let  the  seller  know  the  contract  is 
complete.  However,  you  will  still  note  the  contract  completion  in  your  copy  of  the  project  records. 

Releasing  the  Project  Team 

Releasing  project  team  members  is  not  an  official  process.  However,  it  should  be  noted  that  at  the  conclusion  of 
the  project,  you  will  release  your  project  team  members,  and  they  will  go  back  to  their  functional  managers  or 
get  assigned  to  a  new  project.  You  will  want  to  keep  their  managers,  or  other  project  managers,  informed  as  you 
get  closer  to  project  completion,  so  that  they  have  time  to  adequately  plan  for  the  return  of  their  employees.  Let 
them  know  a  few  months  ahead  of  time  what  the  schedule  looks  like  and  how  soon  they  can  plan  on  using  their 
employees  on  new  projects.  This  gives  the  other  managers  the  ability  to  start  planning  activities  and  scheduling 
activity  dates. 

Final  Payments 

The  final  payment  is  usually  more  than  a  simple  percentage  of  the  work  that  remains  to  be  completed.  Completing 
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the  project  might  involve  fixing  the  most  difficult  problems  that  are  disproportionately  expensive  to  solve,  so  the 
final  payment  should  be  large  enough  to  motivate  the  vendor  to  give  the  project  a  high  priority  so  that  the  project 
can  be  completed  on  time. 

If  the  supplier  has  met  all  the  contractual  obligations,  including  fixing  problems  and  making  repairs  as  noted  on  a 
punch  list,  the  project  team  signs  off  on  the  contract  and  submits  it  to  the  accounting  department  for  final  payment. 
The  supplier  is  notified  that  the  last  payment  is  final  and  completes  the  contractual  agreement  with  the  project. 

Post-Project  Evaluations 

Before  the  team  is  dissolved  and  begins  to  focus  on  the  next  project,  a  review  is  conducted  to  capture  the  lessons 
that  can  be  learned  from  this  project,  often  called  a  lessons-learned  meeting  or  document.  The  team  explores 
what  went  well  and  captures  the  processes  to  understand  why  they  went  well.  The  team  asks  if  the  process  is 
transferable  to  other  projects.  The  team  also  explores  what  did  not  go  well  and  what  people  learned  from  the  expe¬ 
rience.  The  process  is  not  to  find  blame,  but  to  learn. 

Quality  management  is  a  process  of  continual  improvement  that  includes  learning  from  past  projects  and  making 
changes  to  improve  the  next  project.  This  process  is  documented  as  evidence  that  quality  management  practices 
are  in  use.  Some  organizations  have  formal  processes  for  changing  work  processes  and  integrating  the  lessons 
learned  from  the  project  so  other  projects  can  benefit.  Some  organizations  are  less  formal  in  the  approach  and 
expect  individuals  to  learn  from  the  experience  and  take  the  experience  to  their  next  project  and  share  what  they 
learned  with  others  in  an  informal  way.  Whatever  type  of  approach  is  used,  the  following  elements  should  be  eval¬ 
uated  and  the  results  summarized  in  reports  for  external  and  internal  use. 

Trust  and  Alignment  Effectiveness 

The  project  leadership  reviews  the  effect  of  trust — or  lack  of  trust — on  the  project  and  the  effectiveness  of  align¬ 
ment  meetings  at  building  trust.  The  team  determines  which  problems  might  have  been  foreseen  and  mitigated 
and  which  ones  could  not  have  been  reasonably  predicted.  What  were  the  cues  that  were  missed  by  the  team  that 
indicated  a  problem  was  emerging?  What  could  the  team  have  done  to  better  predict  and  prevent  trust  issues? 

Schedule  and  Budget  Management 

The  original  schedule  of  activities  and  the  network  diagram  are  compared  to  the  actual  schedule  of  events.  Events 
that  caused  changes  to  the  schedule  are  reviewed  to  see  how  the  use  of  contingency  reserves  and  float  mitigated 
the  disruption  caused  by  those  events.  The  original  estimates  of  contingency  time  are  reviewed  to  determine  if 
they  were  adequate  and  if  the  estimates  of  duration  and  float  were  accurate.  These  activities  are  necessary  for  the 
project  team  to  develop  expertise  in  estimating  schedule  elements  in  future  projects — they  are  not  used  to  place 
blame. 

A  review  of  budget  estimates  for  the  cost  of  work  scheduled  is  compared  to  the  actual  costs.  If  the  estimates  are 
frequently  different  from  the  actual  costs,  the  choice  of  estimating  method  is  reviewed. 

Risk  Mitigation 

After  the  project  is  finished,  the  estimates  of  risk  can  be  reviewed  and  compared  to  the  events  that  actually  took 
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place.  Did  events  occur  that  were  unforeseen?  What  cues  existed  that  may  have  allowed  the  team  to  predict  these 
events?  Was  the  project  contingency  sufficient  to  cover  unforeseen  risks?  Even  if  nothing  went  wrong  on  this  pro¬ 
ject,  it  is  not  proof  that  risk  mitigation  was  a  waste  of  money,  but  it  is  useful  to  compare  the  cost  of  avoiding  risk 
versus  the  cost  of  unexpected  events  to  understand  how  much  it  cost  to  avoid  risk. 

Procurement  Contracts 

The  performance  of  suppliers  and  vendors  is  reviewed  to  determine  if  they  should  still  be  included  in  the  list  of 
qualified  suppliers  or  vendors.  The  choice  of  contract  for  each  is  reviewed  to  determine  if  the  decision  to  share 
risk  was  justified  and  if  the  choice  of  incentives  worked. 

Customer  Satisfaction 

Relationships  with  the  client  are  reviewed  and  decisions  about  including  the  client  in  project  decisions  and  align¬ 
ment  meetings  are  discussed.  The  client  is  given  the  opportunity  to  express  satisfaction  and  identify  areas  in  which 
project  communication  and  other  factors  could  be  improved.  Often  a  senior  manager  from  the  organization  inter¬ 
views  the  client  to  develop  feedback  on  the  project  team  performance. 

A  general  report  that  provides  an  overview  of  the  project  is  created  to  provide  stakeholders  with  a  summary  of  the 
project.  The  report  includes  the  original  goals  and  objectives  and  statements  that  show  how  the  project  met  those 
goals  and  objectives.  Performance  on  the  schedule  and  budget  are  summarized  and  an  assessment  of  client  satis¬ 
faction  is  provided.  A  version  of  this  report  can  be  provided  to  the  client  as  a  stakeholder  and  as  another  means 
for  deriving  feedback. 

Senior  Management 

The  report  to  senior  management  contains  all  the  information  provided  to  the  stakeholders  in  a  short  executive 
summary.  The  report  identifies  practices  and  processes  that  could  be  improved  or  lessons  that  were  learned  that 
could  be  useful  on  future  projects. 

Archiving  of  Document 

The  documents  associated  with  the  project  must  be  stored  in  a  safe  location  where  they  can  be  retrieved  for  future 
reference.  Signed  contracts  or  other  documents  that  might  be  used  in  tax  reviews  or  lawsuits  must  be  stored.  Orga¬ 
nizations  will  have  legal  document  storage  and  retrieval  policies  that  apply  to  project  documents  and  must  be 
followed.  Some  project  documents  can  be  stored  electronically. 

Care  should  be  taken  to  store  documents  in  a  form  that  can  be  recovered  easily.  If  the  documents  are  stored  elec¬ 
tronically,  standard  naming  conventions  should  be  used  so  documents  can  be  sorted  and  grouped  by  name.  If 
documents  are  stored  in  paper  form,  the  expiration  date  of  the  documents  should  be  determined  so  they  can  be 
destroyed  at  some  point  in  the  future.  The  following  are  documents  that  are  typically  archived: 

•  Charter  documents 

•  Scope  statement 

•  Original  budget 
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•  Change  documents 

•  DPCI  ratings 

•  Manager’s  summary — lessons  learned 

•  Final  DPCI  rating 
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19.  Celebrate! 
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The  project  team  should  celebrate  their  accomplishments,  and  the  project  manager  should  officially  recognize 
their  efforts,  thank  them  for  their  participation,  and  officially  close  the  project.  A  celebration  helps  team  members 
formally  recognize  the  project’s  end  and  brings  closure  to  the  work  they’ve  done.  It  also  encourages  them  to 
remember  what  they’ve  learned  and  start  thinking  about  how  their  experiences  will  benefit  them  and  the  organi¬ 
zation  during  the  next  project. 


Figure  19.1:  Celebrate!  Your  project  is  over. . .  at  least  until  the  next  one. 
Photo  from  Barron  &  Barron  Project  Management  for  Scientists  and 
Engineers,  http://cnx.Org/content/collll20/l.4/ 
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Appendix  1 :  Project  Management  PowerPoints 
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Appendix  2:  Chapter  Questions 


Chapter  2:  Project  Management  Overview 


1.  Everyone  has  been  involved  in  projects.  What  is  the  largest  project  you  have  been  involved  in? 
(You  do  not  have  to  have  been  the  project  manager,  but  could  have  played  another  role.) 

a.  Write  one  sentence  that  describes  the  objective  of  the  project. 

b.  Describe  specifically  how  this  project  meets  the  definition  of  a  project  used  in  this  textbook. 
(How  is  it  unique?  What  were  the  time  constraints?  If  it  is  over,  how  did  you  know  it  was  over? 
If  it  is  ongoing,  how  will  you  know  when  it  is  over? 

c.  What  was  your  role?  Were  you  the  project  manager,  a  volunteer,  some  other  role?  If  you  were 
not  the  project  manager,  who  was? 

d.  Was  the  project  part  of  a  larger  portfolio  or  program  of  projects? 

e.  Who  else  was  involved? 

f .  What  was  the  budget? 

g.  Did  you  anticipate  any  risks  at  the  outset?  Did  the  project  experience  any  outside  forces  that 
caused  a  change  in  either  the  objectives  or  the  approach  to  achieving  those  objectives? 

2.  In  what  ways  can  the  following  activities  be  seen  as  projects?  In  what  ways  do  they  resemble 
ongoing,  routine  business  activities?  Feel  free  to  add  assumptions  and  details  to  describe  how  the 
activity  might  be  a  project  in  one  context  and  routine  in  another. 

a.  Reading  the  chapter  before  attending  a  university  lecture. 

b.  Taking  the  bus  to  work  each  day. 

c.  Piloting  an  aircraft  between  Vancouver  and  Fiji. 

d.  Teaching  a  course  for  the  first  time;  teaching  the  same  course  every  semester. 
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Chapter  3:  The  Project  Life  Cycle  (Phases) 


1.  Go  online  and  search  for  project  life  cycle  models.  Identify  at  least  two  that  are  different  from  the 
PMI  model,  and  compare  and  contrast  the  phases.  Be  sure  to  cite  your  sources. 

2.  How  does  the  application  of  a  phased  approach  to  project  management  vary  in  different  indus¬ 
tries?  Do  you  think  that  the  phases  work  the  same  in  construction  as  they  do  in  event  management  or 
software  development? 


Chapter  5:  Stakeholder  Management 


1.  Identify  a  major  public  infrastructure  project  that  is  either  underway,  complete,  or  proposed  in 
your  region.  This  could  be  a  bridge,  road,  building,  or  something  of  that  nature.  For  the  project  you 
have  identified,  think  of  as  many  stakeholders  and  stakeholder  groups  as  you  can.  Create  a  three-col¬ 
umn  table.  In  column  1,  list  the  stakeholders.  In  column  2,  list  what  each  stakeholder  wants  to  get 
from  the  project.  In  column  3,  list  the  influence  each  stakeholder  has  over  the  project. 

2.  How  can  the  stakeholders  change  over  the  course  of  a  project?  Give  examples  of  changes  in  who 
the  stakeholders  are,  and  also  in  how  their  interests  or  influence  over  the  project  might  change 
throughout  the  term  of  the  project. 


Chapter  7:  Project  Initiation 


1.  Software  project  decision  point. 

a.  You  need  to  determine  an  interest  rate  to  use — select  an  interest  rate  and  explain  why  you 
think  this  number  should  be  used.  Use  it  in  your  calculations  in  item  1.2. 

b.  Given  the  information  below  on  options  1  and  2,  carry  out  three  forms  of  analysis: 
breakeven,  ROI,  and  NPV. 

c.  Make  a  recommendation  on  which  way  to  proceed,  based  on  the  TCO  for  each  option. 

•  Option  1:  Purchase  the  FunSoft  package:  Cost  $200,000  for  software  and  $85,000  for  hardware  in 
year  one;  with  $50,000  to  customize  it  and  a  $40,000  annual  licensing  fee  for  the  life  of  the  contract. 
There  will  be  an  annual  saving  of  $61,000  due  to  the  layoff  of  a  clerk. 

•  Option  2:  Purchase  the  SoftComm  package,  which  will  operate  on  the  vendor’s  hardware:  Cost 
$250,000  for  a  five-year  license,  payable  half  up  front  and  half  during  the  first  year  of  implementa¬ 
tion.  The  maintenance  contract,  at  $75,000  a  year,  includes  all  currently  identified  modifications  to 
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•  Perform  integration  testing — database,  network,  and  user  interface 
When  all  integration  testing  and  user  testing  are  complete,  you  can: 

•  Perform  system  testing 
Then  you  can: 

•  Review  and  revise  documentation 
After  all  other  tasks  are  complete,  you  can: 

•  Obtain  management  approval 
Duration  estimates  for  the  tasks: 

a.  3  days 

b.  10  days 

c.  6  days 

d.  7  days 

e.  20  days 

f.  5  days 

g.  3  days 

h.  2  days 

i.  8  days 

j.  4  days 

k.  5  days 

1.  Create  a  network  diagram  and  a  Gantt  chart  for  the  project  tasks.  Ask  your  instructor  if  you  are 
permitted  to  use  software  such  as  Microsoft  Project  to  help  you  prepare  your  diagrams. 

a.  What  is  the  planned  duration  for  the  testing  project? 

b.  What  is  the  critical  path  for  the  testing  project? 

c.  For  each  task  NOT  on  the  critical  path,  calculate  the  amount  of  slack  available. 

d.  If  the  user  testing  of  the  user  interface  takes  15  days,  what  will  the  impact  be  on  the  project 
duration? 

2.  Go  online  and  find  at  least  two  sites  with  definitions  of  fast  tracking  and  crashing  a  project  sched¬ 
ule. 

a.  Prepare  proper  reference  citations  for  the  sites  you  located,  using  APA  style. 

b.  In  your  own  words,  write  definitions  for  project  fast  tracking  and  project  crashing. 
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c.  Consider  the  plan  you  prepared  for  the  software  system  testing  project  in  question  1  above.  If 
you  were  informed  by  management  that  you  must  reduce  the  planned  duration  of  the  project  by 
five  days,  describe  how  you,  as  a  project  manager,  could  crash  or  fast  track  this  project.  Be  spe¬ 
cific  in  identifying  exacdy  what  could  be  changed  in  the  project  plan  for  each  option. 

d.  (continuation  of  question  2.3)  If  the  request  to  speed  up  the  project  occurs  after  day  25  of  the 
original  schedule,  what  is  the  only  option  available? 

3.  Go  online  and  research  the  difference  between  total  slack  and  free  slack. 

a.  Prepare  proper  reference  citations  for  the  sites  you  located,  using  APA  style. 

b.  Write  definitions  of  total  slack  and  free  slack  in  your  own  words. 

c.  Why  would  the  distinction  between  different  forms  of  slack  be  important  to  a  project  man¬ 
ager? 


Chapter  12:  Budget  Planning 


1.  Wedding  cost  estimation:  Given  the  following  information,  calculate  the  estimated  costs  for  a 
wedding  with  250  guests  and  a  bridal  party  of  six,  using  the  methods  indicated.  Show  your  work. 
Note  that  members  of  the  bridal  party  are  already  counted  as  guests,  you  don’t  need  to  add  them 
twice. 

a.  Parametric  estimate 

b.  Bottom-up  estimate 

c.  Analogous  cost  estimate 

d.  You  will  probably  notice  some  differences  in  the  estimated  values.  Are  these  differences  sig¬ 
nificant?  What  might  cause  the  differences?  If  you  were  estimating  a  significant  project  in  the 
future,  which  method(s)  would  you  use  and  why? 

e.  Your  mother  points  out  you  should  probably  have  valet  parking,  which  will  cost  $500.  Which 
estimate(s)  will  change? 
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Wedding  Cost  Estimates 

Item 

Dollars 

Groom’s  brother’s  wedding,  last  year,  175  guests,  similar 
venue  and  style 

$20,300 

Catering 

$65  per  person 

Photographer 

$1,500 

Rental  of  hall 

$500 

Clothing,  bride 

$2,000 

Clothing,  groom 

$750 

Flowers 

$800 

Other  decor  items 

$500 

Cake 

$500 

Gifts  for  bridal  party 

$80  each 

Wedding  planner 

$2,000 

Wedding  planner’s  estimate  of  typical  cost  for  this  kind  of 
wedding 

$10,000  plus  $75  per 
guest 

2.  Earned-value  analysis.  A  project  budget  calls  for  the 

following  expenditures: 

Task  Date 

Budgeted  Amount 

Build  forms  April  1 

$10,000 

Pour  foundation  April  1 

$50,000 

May  1 

$100,000 

Frame  walls  May  1 

$30,000 

June  1 

$30,000 

Remaining  tasks  July  1  and  beyond 

$500,000 

Define  each  term  in  your  own  words,  calculate  these 
work: 

values  for  the  above  project,  and  show  your 

a.  Budgeted  cost  baseline  (make  a  graph  illustrating  this  one) 

b.  Budget  at  completion  (BAC) 

c.  Planned  value  (PV)  as  of  May  1 

d.  Earned  value  (EV)  as  of  May  1  if  the  foundation  work  is  only  two-thirds  complete.  Every¬ 
thing  else  is  on  schedule. 
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e.  SV  as  of  May  1. 

f.  Actual  cost  as  of  May  1  is  $160,000.  Calculate  the  cost  variance  (CV)  as  of  May  1. 

g.  Schedule  performance  index  (SPI) 

h.  Cost  performance  index  (CPI) 

i.  Estimate  to  complete  (ETC),  assuming  that  the  previous  cost  variances  will  not  affect  future 
costs 

j.  Estimate  at  completion  (EAC) 


Chapter  13:  Procurement  Management 


1.  In  addition  to  cost,  what  factors  should  be  considered  in  selecting  a  building  contractor?  What  can 
go  wrong  if  the  lowest  bid  is  selected  and  nothing  else  is  considered?  (Answer  in  your  own  words, 
maximum  70  words.) 

2.  What  is  the  difference  between  an  RFP  and  an  RFQ?  Give  two  specific  examples  where  an  RFQ 
could  be  used  and  two  specific  examples  where  it  is  more  likely  that  the  organization  will  go  with  an 
RFP.  (Use  examples  NOT  from  your  textbook.) 

3.  Cost  reimbursable  contract  calculation. 

a.  A  contract  calls  for  a  total  payment  of  $800,000  with  a  guarantee.  Essentially  the  contractor 
is  guaranteed  to  make  at  least  $200,000  above  his  costs.  If  the  contractor  can  demonstrate  his 
costs  exceed  $600,000,  the  project  will  pay  the  difference,  with  a  $50,000  ceiling  on  the  over¬ 
age.  The  contractor  demonstrates  he  spent  $623,000.  How  much  (gross)  must  the  project  remit 
to  the  contractor? 

b.  Another  option  for  the  same  contract  has  the  contractor  guaranteed  to  be  paid  his  costs  plus 
20%,  for  costs  that  exceed  $600,000.  With  the  same  initial  assumption — guarantee  of  $800,000 
gross  payment  (no  requirement  to  itemize  costs),  but  if  the  contractor  can  show  that  costs 
exceed  $600,000,  the  project  will  pay  $800,000  plus  the  costs  that  exceed  $600,000,  plus  20% 
of  those  excess  costs,  with  a  ceiling  of  $900,000  gross.  The  contractor  demonstrates  he  spent 
$623,000.  How  much  (gross)  must  the  project  remit  to  the  contractor? 

c.  Under  option  3.2,  at  what  dollar  amount  of  total  costs  would  the  contractor  be  assuming  all 
of  the  excess  costs  beyond  that  point? 

d.  In  which  option  did  the  project  assume  more  of  the  risk  of  a  cost  overrun?  Explain. 
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Chapter  14:  Quality  Planning 


1.  Prepare  a  Pareto  chart  of  the  possible  causes  for  a  student  to  fail  a  final  examination  in  a  univer¬ 
sity  course. 

2.  Vehicles  are  identified  by  RFID  tags  in  order  to  collect  bridge  tolls.  The  project  manager  is  con¬ 
sidering  two  different  technologies  for  RFID  readers.  By  sampling  two  different  options,  the  follow¬ 
ing  data  are  collected  about  the  accuracy  of  the  readers: 

Option  1:  99,  98,  99,  94,  92,  99,  98,  99,  94,  90  Option  2:  98,  97,  97,  97,  98,  98,  97,  97,  98 
Calculate  the  mean,  mode,  and  standard  deviation  of  the  two  options. 


Chapter  1 6:  Risk  Management  Planning 


1.  Describe  the  general  processes  that  should  be  followed  in  managing  risks  throughout  a  project.  Be 
sure  to  include  the  general  sequence  in  which  these  processes  are  carried  out. 

2.  Prepare  a  sample  risk  register  for  a  project  to  put  humans  on  Mars  (four  or  five  risks). 

3.  Prepare  a  probability  versus  impact  matrix  for  your  school’s  Winter  Club  ski  trip  (at  least  four 
identifiable  risks). 

4.  For  one  of  the  risks  you  have  identified  in  question  2  or  3,  describe  how  it  could  be  avoided,  trans¬ 
ferred,  mitigated,  or  accepted. 

5.  What  is  the  difference  between  qualitative  and  quantitative  risk  analysis?  Which  one  is  always 
done?  Why  is  the  other  one  not  always  done  for  every  project? 
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